Dotaz: openvpn s redirect gw a nedostupnost po subnetu

[MilanC]

Ahoj, už nějak moc nevím, tak se dovolím zeptat zde.

Snažím se nakonfigurovat openvpn tak, aby veškerý traffic z klientů byl po navázání tunelu přesměrován do něj. Je to na RPI s raspbianem proti ubuntu serveru. Toto mi nyní funguje, nicméně je zde taková nepříjemná věc... jakmile se tunel naváže přestává být klient/RPI dostupný po lokálním subnetu a nechápu proč. :( Příliš se v těch přidaných routách nevyznám, abych pravdu řekl. FW na RPI jsem zrušil. Jinak pokud jde o ten redirect vše funguje, na serveru je maškaráda a traffic správně jede přes tunel.

Zajímavé je to, že když nechám pinkat v rámci subnetu (z 10.XXX.100.129 -> 10.XXX.100.130), tak na RPI mi přichází icmp request přes eth0. Ale echo reply nikde, ani přes eth0, ani přes iface tunelu. (?)

Konfigurace serveru + klienta: https://justpaste.it/6of7w

Routovací tabulka s navázanou vpn

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         172.20.1.1      128.0.0.0       UG        0 0          0 tap-star01
0.0.0.0         10.XXX.100.129    0.0.0.0         UG        0 0          0 eth0
10.9.100.128    0.0.0.0         255.255.255.252 U         0 0          0 eth0
92.XXX.224.211   10.XXX.100.129    255.255.255.255 UGH       0 0          0 eth0
128.0.0.0       172.20.1.1      128.0.0.0       UG        0 0          0 tap-star01
169.XXX.0.0     0.0.0.0         255.255.0.0     U         0 0          0 tap-star01
172.20.1.0      0.0.0.0         255.255.255.0   U         0 0          0 tap-star01

V této chvíli se z RPI pinknu na gw konektivity, tedy na 10.XXX.10.129 (opačně ale nelze).

Když jsem odmazal ručně první routu (0.0.0.0 172.20.1.1 128.0.0.0) stále z protistrany nepinkám. Až když jsem odmazal druhou (128.0.0.0 172.20.1.1 128.0.0.0), z protistrany jsem na RPI začal pinkat.

Používám unprivileged režim, takže na straně klienta mam konfigurované sudo na ip přes wrapper (podle návodu), toto je myslím ok.

Budu rád za jakoukoliv radu, nakopnutí, vysvětlení... Ta lokální nedostupnost je docela kritická.

Milan

Odpovědi

[NN]

Pravidla v routovaci tabulce se vzdy uplatnuji od konkretniho k vice obecnemu. V tomto pripade spada ICMP dotaz pod:

10.XXX.100.128    0.0.0.0    0 0      255.255.255.252 U 0 0  eth0

a odstraneni dvou nesouvisejicich pravidel by nemelo mit zadny vliv. Problem bych hledal jinde.

[MilanC]

Ahoj, já už to snad trochu pochopil. Dělá to tro def1, které ubere bit z masky v 0.0.0.0/0, čímž vznikne konkrétnější pravidlo 128... A používá se vždy konkrétnější pravidlo z tabulky. Ta finta s 0.0.0.0/1 je tam kuli tomu, aby se v tabulce nepřišlo o default route přepsáním. Můžu se zeptat, k čemu je pak ale ta routa na prvním řádku?

Ještě malý dodatek. Mam úplně stejnou konfiguraci klienta u sebe na stole (druhé RPI), proti stejnému serveru. Zde se mi to neprojevuje, tj. i přes navázanou VPN a redirect trafficu do tunelu je RPI v rámci subnetu dostupné na ICMP, SSH... (zde je to pouze přes switch).

To místo kde mám problém jde přes více síťových prvků, nevím přesně přes kolik, ale jde to vlanou a na nějakém switchi je to pak odtagované a jde do RPI. Jen jestli to nemůže nějak souviset s prostředím, raději jsem doplnil.

[MilanC]

Díky. Vliv to právě mělo, a to mě zaráží, protože je to stejný subnet (lokální doručení paketu), defautl gw by zde neměla hrát žádnou roli. Když RPI rebootnu a pinkám na něj ze subnetu, tak projde cca 15 paketů s odpovědí a pak už nic.Evidentně to koresponduje s nastartováním openvpn. Nějaký nápad? :(

[MilanC]

A nyní jsem si všiml jedné věci. Když je vpn navázaná a pinkám ze subnetu na RPI, tedy neodpovídá. Tak každou sekundu mi do syslogu naskočí následující... Nevím jestli to něčemu napoví. Trochu mě to štve, pač mi to plní syslog. :)

May 24 10:23:30 gw-b827ebc247ae kernel: [  560.779816] IPv4: martian source 10.XXX.100.130 from 178.255.XXX.4, on dev eth0
May 24 10:23:30 gw-b827ebc247ae kernel: [  560.779837] ll header: 00000000: b8 27 eb c2 47 ae 00 25 90 51 75 38 08 00 45 00  .'..G..%.Qu8..E.
May 24 10:23:30 gw-b827ebc247ae kernel: [  560.779847] ll header: 00000010: 00 54 ff ec 40 00 40 01 71 2d                    .T..@.@.q-

[NN]

Mimojine:

92.XXX.224.211   10.XXX.100.129    255.255.255.255 UGH       0 0          0 eth0

Toto neni dobre, takto se neroutuje. Hodila by se konfigurace rozhrani a vypis firewallu.

[MilanC]

Ahoj, tak problém zjištěn mimo vpn, tj. na NATu, ze kterým je RPI umístěno. Opravdu je tam překlad nějak chybně zkonfigurován, takež pokud komunikuji přímo v rámci subnetu, přichází mi na RPI pakety s odlišnou source IP a jsou nejspíš zahozeny. Jelikož jinde problém nemám, tak předpokládám že to bude v pohodě, až to kolegové síťaři upraví/opraví. Díky.