Dotaz: Nejde naroutovat cesta

[LANman]

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?

Odpovědi

[houska]

ip route add default via xx dev yyy?

[Lefo]

S největší pravděpodobností na zařízení tap0 není nakonfigurována podsíť ve které se nachází ip adresa serveru. Musíte zadat tu ip adresu serveru, kterou má server nastavenou pro VPN síť. Nejprve prověřte, zda funguje ping na vnitřní ip adresu serveru, pak má teprve smysl zkoušet nastavit routu. Dále si uvědomte, že po nastavení defaultní routy bude opravdu všechen provoz směrován přez VPN takže i pakety tunelu, proto nejdříve nastavte výjimku pro dosažení veřejné ip adresy serveru, tak aby pakety směřovali přes stávající bránu
ip route add veřejná_ip_serveru/32 via stávající_brána
jinak vám nepude vůbec nic. A default je 0.0.0.0/0 a ne 0.0.0.0/1.

[LANman]

Dekuji 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?

[čavo]

route add -host 1.2.3.4 gw 192.168.0.1 ; udelenie vynimky pre VPN server

route add default gw 10.0.1.100 ; presmerovanie celej prevadzky cez server VPN

Netestol som to, Hádam som sa nepomýlil.

[LANman]

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)

[LANman]

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?

[cynic_asshole]

Na serveru musíš zapnout předávání packetů (FORWARDING)

echo "1" > /proc/sys/net/ipv4/ip_forward

[LANman]

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?

[tomfi]

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.

[DjAARA]

Zkusil bych po nastavení těch rout program 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?).

[LANman]

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?

[linuxik]

Nastavenim firewallu nebo SNAT/Maskarady.

[LANman]

Muzete byt prosim konkretnejsi, tohle zrovna nejsou veci, ve kterych bych se vyznal...

[pupala]

Aká je IP adresa brány, ktorú používa sieť za OpenVPN serverom? 10.0.1.100 ? Alebo 10.0.1.100 je IP OpenVPN servera?

[pupala]

Pošli ešte route -n a ifconfig zo servera.

[moira]

Pokud se jedna o OpenVPN, co volba push "redirect-gateway" ?

[LANman]

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?

[Lefo]

Zkontrolujte, zda je opravdu povolený ip_forward na serveru:
cat /proc/sys/net/ipv4/ip_forward
musí vrátit 1

pokud ano tak je ještě potřeba nastavit na serveru iptables:
1) nesmí pakety zahazovat (tabulka filter)
2) musí provádět maškarádu (tabulka nat)
zkuste vypsat obě tabulky:
iptables -t filter -vnL
iptables -t nat -vnL
tabulka pro filtrování by měla vypadat nějak takto:

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

za předpokladu že eth0 je rozhraní směrující k poskytovateli

tabulka pro natování by měla vypadat nějak takto:

Chain POSTROUTING (policy ACCEPT)
MASQUERADE  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0

za předpokladu že eth0 je rozhraní směrující k poskytovateli

je vhodné povolit pouze vnitřní podsíť, ale není to nutné.

iptables musí být také zapnuté - stav iptables se dá obvykle zjistit pomocí
/etc/init.d/iptables status

Pokud problémy přetrvají můžete zkusit nějaký sniffer na serveru (tshark nebo wireshark) velmi vám to pomůže zjistit kde je problém.
Někdy je lepší místo traceroute použít příkaz ping s parametrem -t # kde za # dosadíte číslo hopu.

[LANman]

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#

[Lefo]

Ano jak sem řekl .. bez maškarády vám to fungovat nemůže..
zkuste:
iptables -t nat -A POSTROUTING -o eth0 -s 10.0.1.0/24 -j MASQUERADE
za eth0 dosaďte rozhraní směrující k internetu.

pokud vám to stále nepude, zkuste nainstalovat tshark a spustit ho:
tshark -i tap0
a pingovat od klienta někam ven. Na tsharku uvidíte příchozí ICMP pakety zdrojová ip by měla být lokální ip klienta a cílová by měla být schodná s cílovou ip.
Pak zkuste spustit tshark na rozhraní k ISP:
tshark -i eth0
Měli by být vidět pakety odcházející k ISP a zdrojová adresa by se měla změnit za veřejnou ip adresu serveru.
Opačná změna by se měla dít pro příchozí pakety.
Pro zvýšení bezpečnosti byste měl vytvořit i záznamy ve filtrovací tabulce.
Nezapomeňte si pak uložit nastavení iptables (příkaz iptables-save) obnova (iptables-restore).
Vaše distribuce by ale měla mít vestavěný nastavování iptables, takže pokud možno použijte to.

[LANman]

Ok, 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.

[LANman]

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?

[Lefo]

Odpovídá - /24 je ekvivalentní k 255.255.255.0

[Lefo]

Tak bude pravděpodobně problém v maškarádě.
Zkuste iptables -t nat -vnL
co nyní příkaz vypíše?
nalevo (pkts) by mělo být uvedeno kolikrát se pravidlo ujalo. Pokud je tam nula tak se zřejmě nesplní nějaké kritérium, nebo pokud je i v POSTROUTING (0 packets), tak se z nějakého důvodu neprovádí POSTROUTING.
Možná bude potřeba iptables nějak zapnout.

[LANman]

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

[DjAARA]

Jak již bylo řečeno výše, maska /24 je to samé jako 255.255.255.0. Viz například

$ 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

[LANman]

Aha, nejak jsem si toho nevsiml, uz je mi to jasne...

[tomk]

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

 

[LANman]

1) ano

2) eth1 je rozhrani mirici do internetu, eth0 na danem pocitaci (serveru) je disabled.

[tomk]

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

[Lefo]

Je evidentní, že pakety prochájí, takže iptables a POSTROUTING běží, problém je v tom, že se nenačítá pkts. To znamená, že se nesplní nějaké kritérium (jak už jsem psal). Je tedy eth0 skutečně rozhraním směrujícím k ISP ?
jak jsem psal "za eth0 dosaďte rozhraní směrující k internetu".
podle vašeho tshark -i eth1 bych soudil, že tam má být eth1.

[Lefo]

Aby to teda bylo uplně jasné, zkuste:

iptables -t nat -F POSTROUTING
iptables -t nat -A POSTROUTING -o eth1 -s 10.0.1.0/24 -j MASQUERADE

[pupala]

Inak tap je rozhranie pre bridge a neroutuje sa cez neho, na to je tun. Default routa na klientovi openvpn musi byť presne tá istá ako na serveri, ak je použité rozhranie tap. Zato som chcel v predošlom výpis ifconfig a route -n zo servera.

[LANman]

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.

[houska]

nedela to dnska? zkus pingat ip adresu (napr. 77.75.76.3)

[LANman]

Pingovani domenovych jmen i IP adres funguje. Co nefunguje je traceroute.

[houska]

mno tak jediny co me napada ze ti nekdo blokuje UDP na portu 53 na kterem traceroute funguje, zkus jiny port

[LANman]

No celkem pochybuju ze 53 je blokovany, ale muzu to vyzkouset, jak donutim traceroute pouzit jiny port?

[houska]

man traceroute

[Lefo]

traceroute vybere náhodný UDP port a pak ho s každým paketem incrementuje. Mení divu, že vám to nefunguje. Zkuste použít traceroute s parametrem -I pak se použije ICMP. Pokud použijete parametr -p tak vám to stejně nepude, protože tím parametrem nastavujete jen počáteční port, ale pro další pakety se použijí vyšší porty. Pokud použijete -I tak se odešle standardní ping request a odpovědi se rozliší podle shody identifikátorů a sekvenčního čísla v ICMP paketu.

[moira]

Co vypíše iptables -L a iptables -t nat -L na serveru?

[LANman]

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#