Klient OpenVPN dosiahne server, ale nie hosty v LAN: kontrolný zoznam

Klient hlási pripojené, adresa tunela odpovedá na ping a nič v kancelárskej LAN nereaguje. Vidím to po takmer každej aktualizácii klienta a prvý inštinkt je otvoriť firewall, čo je zvyčajne nesprávny krok: tunel je v poriadku a prerušenie je na jednom z troch skokov, ktoré paket musí prejsť. Prejdite cestu v poradí, v akom ju paket absolvuje, najprv trasa klienta, potom preposielanie na serveri, potom cesta späť, a vinníka poruchy nájdete za pár minút.

Prvý krok: sledujte rozhodnutie klienta o smerovaní

Skôr než sa dotknete servera, dokážte, že klient posiela paket do tunela. Spýtajte sa jadra, ktoré rozhranie by použilo pre jedného konkrétneho hosta v LAN, namiesto čítania celej tabuľky:

ip route get 192.168.50.10

Ak odpoveď uvádza váš fyzický adaptér a kancelársku bránu, žiadna zmena na strane servera nepomôže. OpenVPN rozdáva trasy len vtedy, keď ich server pretlačí, preto hľadajte push "route 192.168.50.0 255.255.255.0" v konfigurácii servera a potom klienta znova pripojte. Väčšina klientov aplikuje pretlačené trasy pri pripojení, nie pri opätovnom načítaní profilu.

V systéme Windows má tá istá otázka iný príkaz. Find-NetRoute -RemoteIPAddress 192.168.50.10 vypíše rozhranie a ďalší skok, ktorý by zvolil zásobník, a route print -4 ukáže, či pretlačený prefix vôbec existuje.

Druhý krok: potvrďte, že server paket prepošle

Ak je trasa klienta správna, paket dorazí na server a server musí súhlasiť s jeho preposlaním. Prepínač jadra je prvá brána a sysctl net.ipv4.ip_forward musí vrátiť 1. Nastavenie pomocou echo 1 > /proc/sys/net/ipv4/ip_forward funguje do ďalšieho reštartu, a práve preto sa tá istá sťažnosť vracia o týždne neskôr.

Zapíšte to niekam, čo prežije reštart:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

Druhou bránou je tabuľka filtrov. Hostiteľ s nainštalovaným Dockerom často nesie politiku FORWARD nastavenú na DROP a tunel toto rozhodnutie dedí. iptables -L FORWARD -v -n ukazuje aj politiku, aj počítadlá paketov; ak je politika DROP, preposielanie potrebuje výslovné povolenie pre smer z tunela do LAN a ďalšie pre odpoveď.

Tretí krok: sledujte paket do LAN a hľadajte odpoveď

Sledujte obe strany servera súčasne. Zachytávajte na tuneli aj na rozhraní LAN, filtrované na jedného klienta a jedného hostiteľa, aby výstup zostal čitateľný:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

Požiadavky, ktoré sa objavia na tun0 a znova na eth0 so zdrojom 10.8.0.x, po ktorých nasleduje ticho, znamenajú, že paket dorazil a odpoveď odišla inam. Hostiteľ v LAN odpovedá svojej predvolenej bráne, tá brána nemá trasu pre fond VPN a odpoveď umiera na routeri LAN. Ping na hostiteľa v LAN zo servera o tejto ceste nič nedokazuje, pretože táto prevádzka nikdy neprekročí tunel.

Štvrtý krok: vyberte medzi prekladom a spiatočnou trasou

Dve opravy dieru uzavrú a voľba má dôsledky aj mimo toho, či ping funguje. Preklad zdroja robí zo servera zdanlivého odosielateľa:

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Obmedzte pravidlo na fond a rozhranie LAN, potom ho urobte trvalým, inak ďalšie načítanie firewallu vašu opravu ticho odstráni. Cenou je identita: každý klient vyzerá v protokoloch LAN a v pravidlách prístupu ako server VPN a per-client policy becomes guesswork.

Statická trasa pre 10.8.0.0/24 na routeri LAN, mieriaca na server VPN, udržiava adresy klientov viditeľné a je lepšou dlhodobou odpoveďou, keď je ten router váš. Mnoho lokalít nejaký čas prevádzkuje oboje, NAT pre okamžitú opravu a trasu, keď je napísaná politika firewallu. Ak je server peer site-to-site a nie fond, strana servera potrebuje aj iroute pre vzdialenú podsietu, inak trasa peeru existuje, ale prevádzka klientov sa s ňou nikdy nespája.

Piaty krok: overte to z klienta a zapíšte, čo sa zmenilo

Uzavrite slučku z klienta, nie zo servera. Pripojte sa k skutočnej službe na hostiteľovi v LAN a potom potvrďte, že počítadlá prekladu sa posunuli pomocou iptables -t nat -L POSTROUTING -v -n, pretože pravidlo s nulovými paketmi je pravidlo, ktoré nikdy nesedelo. conntrack -L -s 10.8.0.5 ukáže tok a jeho stav, keď potrebujete dôkaz, že spiatočný smer je sledovaný.

Nechajte v konfigurácii servera poznámku: ktorá podsieť, ktoré rozhranie, ktoré pravidlo a či router LAN nesie spiatočnú trasu. Keď nabudúce aktualizácia klienta zmaže pretlačenú trasu, tá poznámka premení hasenie požiaru na opravu na jeden riadok.