OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Oznámeny byly nové Raspberry Pi Compute Module 4S. Vedle původní 1 GB varianty jsou nově k dispozici také varianty s 2 GB, 4 GB a 8 GB paměti. Compute Modules 4S mají na rozdíl od Compute Module 4 tvar a velikost Compute Module 3+ a předchozích. Lze tak provést snadný upgrade.
Po roce vývoje od vydání verze 1.24.0 byla vydána nová stabilní verze 1.26.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.26.
Byla vydána nová verze 6.2 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.14.
Byla vydána nová verze 30.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí JavaScriptu, HTML a CSS Electron (Wikipedie, GitHub). Chromium bylo aktualizováno na verzi 124.0.6367.49, V8 na verzi 12.4 a Node.js na verzi 20.11.1. Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.
Byla vydána nová verze 9.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 220 vývojářů. Provedeno bylo více než 2 700 commitů. Přehled úprav a nových vlastností v seznamu změn.
Dobry den, zprovoznil jsem si na serveru vpn, po pripojeni se mi vytvori zarizeni tap0 a dostanu na nej IP adresu. Jedine, co mi zbyva, je naroutovat vsechen provoz z meho pocitace na dany server. Tyto pokusy vsak selhavaji:
$ sudo route add -net 0.0.0.0 gw ip_serveru dev tap0 SIOCADDRT: No such process $ sudo ip route add 0.0.0.0/1 via ip_serveru dev tap0 RTNETLINK answers: No such process
Cim to muze byt zpusobeno?
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
24.9.2009 18:27
ip route add veřejná_ip_serveru/32 via stávající_bránaDekuji za podrobny popis, bohuzel me znalosti siti nejsou zas tak vysoke, mozna kdybyste mi to vysvetlil primo na me konfiguraci.
Jeste nez se pripojim na vpn tak to vypada takto:
$ ifconfig wlan0
wlan0 Link encap:Ethernet HWaddr 00:13:E7:5F:19:1A
inet addr:192.168.0.5 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::213:e8ff:fe5f:181f/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:26656 errors:0 dropped:0 overruns:0 frame:0
TX packets:19541 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:19848505 (18.9 Mb) TX bytes:4006347 (3.8 Mb)
$ route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 wlan0
Po pripojeni na vpn se objevi interface tap0:
$ ifconfig tap0
tap0 Link encap:Ethernet HWaddr 36:F8:AF:73:D8:56
inet addr:10.0.1.1 Bcast:10.0.1.255 Mask:255.255.255.0
inet6 addr: fe80::34f8:afff:fe73:d856/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:3 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:238 (238.0 b)
a routovaci tabulka vypada takto:
$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 wlan0
Verejna IP adresa vpn serveru je pro zjednoduseni 1.2.3.4 a jeho adresa ve VPN siti je 10.0.1.100. Maska ve VPN siti je 255.255.255.0. ping 10.0.1.100 funguje. Co mam tedy udelat ted?
Po teto akci vypada routing table takto:
$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 158.194.136.86 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan0 10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 0.0.0.0 10.0.1.100 0.0.0.0 UG 0 0 0 tap0 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 wlan0
10.0.1.100 pingovat mohu, ale do internetu nemohu (ping google.com nefunguje)
Tak jsem zkousel ruzne kombinace az jsem v tom docista zamotal. Kazdopadne co potrebuji je, kdyz zadam u sebe "ping google.com", pak aby ten paket letel napred na vpn server a az pak do sveta. Je toto zalezitost nastaveni routovani u klienta nebo musim provest i nejake zasahy do routovaci tabuly serveru?
25.9.2009 18:39
echo "1" > /proc/sys/net/ipv4/ip_forward
Ok, forwarding jsem zapnul.
Routing table vypada takto:
$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 158.194.136.86 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan0 10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 0.0.0.0 10.0.1.100 0.0.0.0 UG 0 0 0 tap0
a traceroute na google takto:
$ traceroute google.com traceroute to google.com (74.125.45.100), 30 hops max, 40 byte packets 1 10.0.1.100 (10.0.1.100) 28.969 ms 41.833 ms 29.416 ms 2 * *
To znamena, ze na vpn server do dojde, ale co se stane pak? Proc to nefunguje?
Na ten vpn server to vypadá že dojde... teď bude problém na něm. (nat, routing, policy, filtry...).
Podle toho co vidím hádám, že jste ještě nezměnil dns směrem k dns serveru, který slouží u toho vpn serveru... při provozu se mohou objevit některé problémy s nečekanou odpovědí na dns dostaz (hlavně pokud bude server v lokální síti vašeho poskytovatele připojení, nebo naopak v síti u vpn serveru). Dále můžete podle konfigurace pravděpodobně očekávat problémy s velkými rámci... no ale myslím, že teď Vám jde hlavně o ten ping, takže vše na serveru zkontrolovat, jestli je tak jak potřebujete.
25.9.2009 20:24
DjAARA | skóre: 32
| Praha|Náklo|Olomouc
traceroute, například traceroute 74.125.67.100, aby jsme viděli, kudy se snaží s danou ip adresou spojit. Pokud bude jako první skok VPN server na druhé straně, tak pak bude chyba na něm (možná nepovolený ip_forward, firewall, překlad adres?).
Ok, takze viz muj prispevek vyse, traceroute ukazal ze ping leti na VPN server. Na serveru je zapnuty ip_forward. Jak nyni zjistim blize cim to muze byt?
Tak jsem tento radek zapsal do konfigurace serveru a restartoval ho, ale stale to same...
Pokud mam routing tabe takto:
$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 158.194.136.86 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan0 10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 0.0.0.0 10.0.1.100 0.0.0.0 UG 0 0 0 tap0 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 wlan0
tak mohu pingovat vnitrni IP serveru (10.0.1.100), ale nemohu pingovat google. Navic traceroute google.com ukazuj toto:
traceroute google.com traceroute: Warning: google.com has multiple addresses; using 74.125.67.100 traceroute to google.com (74.125.67.100), 30 hops max, 40 byte packets 1 * * * 2 * *
neukazuje zadny skok, takze ani nevim kam ten ICMP paket leti. Zkusil jsem tedy odstranit default gw 192.168.0.1, potom routovaci tabulka vypada takto:
$ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 158.194.136.86 192.168.0.1 255.255.255.255 UGH 0 0 0 wlan0 10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 tap0 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 0.0.0.0 10.0.1.100 0.0.0.0 UG 0 0 0 tap0
Stale mohu pingovat 10.0.1.100, google.com nemuzu. Traceroute vsak uz ukazuje toto:
$ traceroute g traceroute to www.google.com (74.125.45.100), 30 hops max, 40 byte packets 1 10.0.1.100 (10.0.1.100) 29.738 ms 34.632 ms 28.715 ms 2 * * *
Takze pingovaci paket dorazi alespon na VPN server. Jinak ze serveru (10.0.1.100) muzu sebe pingovat (10.0.1.1). Nejake navrhy co zkusit nyni?
Chain FORWARD (policy DROP)
ACCEPT all -- tap0 eth0 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- eth0 tap0 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
Chain POSTROUTING (policy ACCEPT)
MASQUERADE all -- * eth0 0.0.0.0/0 0.0.0.0/0
brea:/home/user# cat /proc/sys/net/ipv4/ip_forward 1 brea:/home/user# /etc/init.d/iptables status bash: /etc/init.d/iptables: No such file or directory brea:/home/user# iptables -t filter -vnL WARNING: All config files need .conf: /etc/modprobe.d/nvidia-kernel-nkc, it will be ignored in a future release. Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination brea:/home/user# iptables -t nat -vnL Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination brea:/home/user#
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.1.0/24 -j MASQUERADEOk, udelal jsem to presne podle toho navodu. Pri sudo tshark -i tap0 jsem videl toto:
69.272133 10.0.1.1 -> 74.125.45.100 ICMP Echo (ping) request
Takze to je presne jak jste psal, ale pri tshark -i eth1 vidim take toto:
0.504699 10.0.1.1 -> 74.125.45.100 ICMP Echo (ping) request
Takze zdrojova adresa se na verejnou IP adresu serveru neprepsala... proc?
Jinak distribuce bezici na serveru je debian.
Btw, maska te vnitri site (10.0.1.*) je 255.255.255.0 - coz neodpovida tomu /24 z toho iptables pravidla co jste psal - muze toto zpusobovat problemy?
Chain POSTROUTING (policy ACCEPT 6210 packets, 487K bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- * eth0 10.0.1.0/24 0.0.0.0/0
Co tedy ta maska 10.0.1.0/24 - viz muj prispevek nad vasim, muze prave ta maska byt kriteriem co se nesplni?. Distribuce je debian, soubor /etc/init.d/iptables ale neexistuje. V systemu jsou tyto prikazy:
$ sudo iptables iptables iptables-apply iptables-restore iptables-save iptables-xml
28.9.2009 10:23
DjAARA | skóre: 32
| Praha|Náklo|Olomouc
$ ipcalc 10.0.1.0/24 Address: 10.0.1.0 00001010.00000000.00000001. 00000000 Netmask: 255.255.255.0 = 24 11111111.11111111.11111111. 00000000 Wildcard: 0.0.0.255 00000000.00000000.00000000. 11111111 => Network: 10.0.1.0/24 00001010.00000000.00000001. 00000000 HostMin: 10.0.1.1 00001010.00000000.00000001. 00000001 HostMax: 10.0.1.254 00001010.00000000.00000001. 11111110 Broadcast: 10.0.1.255 00001010.00000000.00000001. 11111111 Hosts/Net: 254 Class A, Private Internet
Pro jistotu bych se zeptal na dve otazky:
1) Ten vypis iptables je proveden na serveru?
2) eth0 - je rozhrani mirici do Internetu? Protoze o kousek vyse bylo pro sledovani provozu tsharkem na internetovem rozhrani dosazovano "-i eth1"
Tomas
1) ano
2) eth1 je rozhrani mirici do internetu, eth0 na danem pocitaci (serveru) je disabled.
Tak v tom pripade je jasne, ze to co ve vypisu
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.1.0/24 -j MASQUERADE
nesedi je parametr -o eth0. Jak je uz ostatne napsano i v dalsich prispevcich.
Tomas
iptables -t nat -F POSTROUTING
iptables -t nat -A POSTROUTING -o eth1 -s 10.0.1.0/24 -j MASQUERADE
Ano, dekuji, spletl jsem to, pouzil jsem eth0 misto eth1, ted uz mohu pingovat do internetu.
Mam vsak jeste jeden dotaz. Proc nefunguje traceroute (treba google.com) - vystupem jsou jen hvezdicky a nevidim zadne hopy i kdyz je jasne ze ten pozadavek projde tam i zpet.
Pingovani domenovych jmen i IP adres funguje. Co nefunguje je traceroute.
iptables -L a
iptables -t nat -L
na serveru?
brea:/home/user# iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination brea:/home/user# iptables -t nat -L Chain PREROUTING (policy ACCEPT) target prot opt source destination Chain POSTROUTING (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination brea:/home/user#
Tiskni
Sdílej:
