Dvě brány, jedna VPN: proč OpenVPN volí špatné vzestupné rozhraní

Dvě vzestupná rozhraní, jeden tunel a provoz odchází tím, které jste nezvolili. Privátní podsítě jsou dostupné, log hlásí úspěšné připojení a nese ho právě měřené rozhraní. Nic ve výstupu OpenVPN nezmiňuje bránu, protože klient žádnou nikdy nezvolil. Otevřel socket na vzdálenou adresu a nechal jádro rozhodnout, jak se k této adrese dostat.

Adresa tunelu není koncový bod

V každé relaci existují dvě různé cesty. Vnější cesta nese šifrovaný transport k veřejné adrese serveru. Vnitřní cesta nese vše, co server strká do tunelu, a pravidla směrování pro jednu nemají vliv na druhou.

Záznam remote v profilu pojmenovává vnější cíl, takže to je adresa, kterou je třeba připevnit. Je to také hodnota, která se mění, když se název hostitele přeloží jinak nebo profil uvádí několik remote.

Najděte adresu, na kterou klient skutečně volal

Čtěte živý socket, ne konfigurační soubor. Tabulka socketů ukazuje protějšek, ke kterému se proces skutečně připojil, a to je hodnota, se kterou se výjimka musí shodovat. Profil lze upravit po začátku relace a socket je jediným důkazem toho, na co se volalo:

ss -tunp | grep -i openvpn
journalctl -u openvpn-client@work --no-pager | grep -i "Peer Connection Initiated"

Řádek v logu uvádí adresu a port protějšku v okamžiku připojení. Pokud se neshoduje s profilem, něco před klientem přepisuje cíl dřív, než připojení začne.

Zkontrolujte také rodinu adres. Profil s dvojím zásobníkem se může připojit přes IPv6, zatímco vaše výjimka pokrývá jen IPv4, a provoz pak sleduje jiné pravidlo než to, které jste napsali. Totéž platí pro proxy, která odpovídá jménem koncového bodu. Oba případy vytvářejí tunel, který funguje, zatímco vaše trasa nic nedělá.

Připevněte koncový bod a přečtěte si pořadí zásad

Trasa k hostiteli je konkrétnější než jakákoli výchozí trasa. Proto /32 pro adresu protějšku vítězí v tabulce, která ji obsahuje. Obvyklý tvar výslovně uvádí bránu a zařízení:

ip route add 203.0.113.40/32 via 192.168.10.1 dev eth0

Tato trasa pomůže jen tehdy, když se vyhledávání dostane do této tabulky. Pravidla zásad se vyhodnocují v pořadí a první shoda rozhoduje, takže pravidlo, které posílá vše do druhé tabulky, obchází vaši trasu k hostiteli v main. Přečtěte si pravidla, než budete předpokládat, že trasa je směrodatná:

ip rule show
ip route get 203.0.113.40

Zeptejte se druhého příkazu se stejnou zdrojovou adresou nebo značkou, kterou klient používá, když na nich zásada závisí. Hlásí trasu, kterou by jádro vybralo, což je důkaz o vyhledávání, a ne důkaz, že živý socket tuto cestu používá.

Když se koncový bod přesune

Název hostitele, který se překládá na několik adres, zneplatní trvalou /32, jakmile se odpověď změní. Profil s více řádky remote má stejný problém, protože klient může přistát na kterémkoli z nich. Obnovujte trasu z vlastních háků životního cyklu klienta, místo abyste ji přidávali ručně. Skript up, který čte dohodnutý protějšek a instaluje trasu k hostiteli, udržuje výjimku v souladu s realitou, a odpovídající skript down ji odstraňuje.

Obnovení zaznamenejte na stejné místo jako zbytek konfigurace směrování hostitele. Trasa, která existuje jen do dalšího restartu, je test, ne oprava.

Udržujte vnitřní zásadu odděleně

Přesun vnější cesty neposkytuje přístup k nové privátní podsíti a nemění, které cíle server strká do tunelu. Trasa spodní vrstvy volí drát; vstrčené trasy volí, co vstoupí do tunelu. Právě oddělení těchto dvou rozhodnutí dělá rozdělení předvídatelným.

Pokud je cílem jen udržet šifrovaný transport mimo měřené rozhraní, nechte výchozí trasu být a přidejte jedinou výjimku pro hostitele. Nahrazení celostrojové výchozí trasy kvůli přesunu jednoho VPN připojení rozbije každou další aplikaci na hostiteli.

Potvrďte výsledek dvěma nezávislými pozorováními: místní adresou a zařízením socketu a trasou, na kterou se překládá privátní cíl. Když obojí odpovídá vašemu záměru, rozdělení je skutečné. Manuál OpenVPN 2.6 pokrývá volby remote a místního navázání, které rozhodují, na kterou adresu klient volá.