Klient OpenVPN dosáhne na server, ale ne na hostitele v LAN: kontrolní seznam

Klient hlásí připojeno, adresa tunelu odpovídá na ping a nic v kancelářské LAN nereaguje. Vidím to po téměř každém upgradu klienta a první instinkt je otevřít firewall, což je obvykle špatný krok: tunel je v pořádku a přerušení je na jednom ze tří skoků, kterými paket musí projít. Projděte cestu v pořadí, v jakém ji paket absolvuje – nejprve trasa klienta, pak předávání na serveru, pak cesta zpět – a viníka poruchy najdete během několika minut.

První krok: sledujte rozhodnutí klienta o směrování

Než sáhnete na server, dokažte, že klient posílá paket do tunelu. Zeptejte se jádra, které rozhraní by použilo pro jednoho konkrétního hostitele v LAN, místo abyste četli celou tabulku:

ip route get 192.168.50.10

Pokud odpověď uvádí váš fyzický adaptér a kancelářskou bránu, žádná změna na straně serveru nepomůže. OpenVPN rozdává trasy jen tehdy, když je server protlačí, takže hledejte push "route 192.168.50.0 255.255.255.0" v konfiguraci serveru a poté klienta znovu připojte. Většina klientů aplikuje protlačené trasy při připojení, ne při načtení profilu.

Ve Windows má stejná otázka jiný příkaz. Find-NetRoute -RemoteIPAddress 192.168.50.10 vypíše rozhraní a další skok, který by zásobník zvolil, a route print -4 ukáže, zda protlačený prefix vůbec existuje.

Druhý krok: potvrďte, že server paket předá dál

Pokud je trasa klienta správná, paket dorazí na server a server musí souhlasit s jeho předáním. Přepínač jádra je první branou a sysctl net.ipv4.ip_forward musí vrátit 1. Nastavení pomocí echo 1 > /proc/sys/net/ipv4/ip_forward funguje do dalšího restartu, a právě proto se stejná stížnost vrací o týdny později.

Zapište to někam, co přežije restart:

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

Druhou branou je tabulka filtrů. Hostitel s nainstalovaným Dockerem často nese politiku FORWARD nastavenou na DROP a tunel toto rozhodnutí dědí. iptables -L FORWARD -v -n ukazuje jak politiku, tak počítadla paketů; pokud je politika DROP, předávání potřebuje výslovné povolení pro směr z tunelu do LAN a další pro odpověď.

Třetí krok: sledujte paket do LAN a hledejte odpověď

Sledujte obě strany serveru současně. Zachycujte na tunelu i na rozhraní LAN, filtrováno na jednoho klienta a jednoho hostitele, aby výstup zůstal čitelný:

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

Požadavky, které se objeví na tun0 a znovu na eth0 se zdrojem 10.8.0.x, po nichž následuje ticho, znamenají, že paket dorazil a odpověď odešla jinam. Hostitel v LAN odpovídá své výchozí bráně, ta brána nemá trasu pro fond VPN a odpověď umírá na routeru LAN. Ping na hostitele v LAN ze serveru o této cestě nic nedokazuje, protože tento provoz nikdy tunel nepřekročí.

Čtvrtý krok: vyberte mezi překladem a zpáteční trasou

Dvě opravy díru uzavřou a volba má důsledky i mimo to, zda ping funguje. Překlad zdroje dělá ze serveru zdánlivého odesílatele:

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

Omezte pravidlo na fond a rozhraní LAN, pak ho zpřístupněte trvale, jinak příští načtení firewallu vaši opravu tiše odstraní. Cena je identita: každý klient vypadá v protokolech LAN a v přístupových pravidlech jako server VPN a per-client policy becomes guesswork.

Statická trasa pro 10.8.0.0/24 na routeru LAN, mířící na server VPN, udržuje adresy klientů viditelné a je lepší dlouhodobou odpovědí, když je ten router váš. Mnoho lokalit nějakou dobu provozuje obojí, NAT pro okamžitou opravu a trasu, jakmile je napsaná politika firewallu. Pokud je server peer site-to-site a ne fond, potřebuje strana serveru také iroute pro vzdálenou podsíť, jinak trasa peeru existuje, ale provoz klientů se s ní nikdy nespojí.

Pátý krok: ověřte to z klienta a zapište, co se změnilo

Uzavřete smyčku z klienta, ne ze serveru. Připojte se ke skutečné službě na hostiteli v LAN a potom potvrďte, že se počítadla překladu posunula pomocí iptables -t nat -L POSTROUTING -v -n, protože pravidlo s nulovými pakety je pravidlo, které nikdy neodpovídalo. conntrack -L -s 10.8.0.5 ukáže tok a jeho stav, když potřebujete důkaz, že zpětný směr je sledován.

Nechte v konfiguraci serveru poznámku: která podsíť, které rozhraní, které pravidlo a zda router LAN nese zpáteční trasu. Až příště upgrade klienta smaže protlačenou trasu, ta poznámka promění hašení požáru v opravu na jeden řádek.