Co route-nopull v OpenVPN skutečně zastaví, že server posílá

Dali jste route-nopull do klientského profilu, aby tunel nespolykal vaši výchozí trasu, a teď je kancelářská podsíť nedostupná, zatímco klient stále tvrdí, že je připojený. Obě pozorování jsou pravdivá a nic neselhalo. Přepínač říká klientovi, aby přeskočil trasy a položky DHCP, které server posílá, což je užší instrukce, než většina lidí při přidání očekává. Co zůstává, je funkční tunel bez názoru na to, které cíle ho mají používat.

Tato mezera je celé rozhodnutí, o kterém tento článek je. Buď síť popisuje server, nebo klient, a přepínač předává tuto práci klientovi, aniž by za vás cokoli z ní udělal.

Co přepínač při připojení vypne

Klient OpenVPN, který táhne, obvykle po autentizaci převezme od serveru balík: trasy, přesměrování výchozí brány, servery DNS a několik ladicích direktiv. Když je route-nopull v platnosti, klient stále přijímá relaci, stále ověřuje certifikáty, stále vyjednává šifry a keepalive a stále zvedá rozhraní. Co zahazuje, je aplikace posílaných řádků route a posílaných řádků dhcp-option, včetně DNS.

Zmatek pochází ze zeleného indikátoru vedle mrtvé aplikace. Tunel existuje; mapování cílů na tento tunel ne. Nic na stavovém panelu klienta nerozlišuje „připojeno a směruje“ od „připojeno a nečinné“, protože z pohledu tunelu jsou to oba stejné stavy.

Proč živý tunel přesto nemusí směrovat nic

Rozhraní se objeví s vlastní adresou a na spoji bod-bod často nemá nic konkrétnějšího než trasu hostitele k protějšku. Soukromá podsíť se stane dostupnou jen tehdy, když nějaká trasa ukazuje na toto rozhraní se správným prefixem, a při vypnutém posílání tato trasa nikdy nedorazí. Stažený profil obvykle také nepomůže, protože byl napsán s předpokladem, že server dodá právě tuto informaci. Proto rozhraní může vypadat zdravě, zatímco podsíť zůstává temná.

Čtení profilu tedy dokazuje velmi málo. Čtěte běžící stav, na připojeném stroji:

ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10

Adresa bez trasy podsítě ve druhém příkazu je podpisem tohoto problému. Třetí příkaz pak odpovídá na otázku, která uživatele skutečně zajímá, protože hlásí rozhraní, které by jádro zvolilo pro konkrétní cíl, namísto seznamu, o kterém jste doufali, že ho použije. Pokud odpovídá přes vaše fyzické spojení, tunel vůbec není na cestě.

Překlad jmen selhává ze souvisejícího důvodu, ne z odděleného. Posílané položky dhcp-option DNS se přeskakují stejným přepínačem, takže dotazy na interní hostitele jdou k tomu resolveru, který poskytla místní síť. Ten resolver nemá zónu pro kancelář, takže dotaz selže nebo vrátí veřejnou odpověď, a selhání vypadá jako problém serveru, když je to problém klientské konfigurace. Testování adresy před jménem je to, co obojí odděluje.

Volba mezi přepínačem a filtrem prefixů

Obě možnosti řeší různé podoby stejné stížnosti a špatná volba je to, co vytváří stav připojeno, ale nepoužitelné. Jedna nahrazuje posílanou politiku jako celek, druhá ji upravuje podle prefixu. Tabulka uvádí krátkou verzi a odstavec za ní pokrývá část, která lidi zaskočí.

pull-filter je porovnávač prefixů se třemi slovesy, takže může přijmout rodinu řádků, tiše je ignorovat nebo připojení úplně odmítnout, když se prefix objeví. Právě to poslední chování stojí za to znát: pravidlo odmítnutí mění nesouhlas v politice na neúspěšný handshake místo tichého vynechání. Manuál OpenVPN 2.6 uvádí přijímané prefixy a přesnou sémantiku každého slovesa.

Častou střední cestou je odmítnout pouze redirect-gateway a nechat kancelářské trasy a DNS dorazit podle záměru. To udržuje posílání funkční pro části, kterým server rozumí lépe než vy, a zároveň brání tomu jedinému řádku, který by převzal vaši výchozí trasu.

Ruční přidání tras a resolveru

Pokud přepínač ponecháte, profil musí říci, co by řekl server. Klientské direktivy route se aplikují po navázání spojení, takže fungují vedle přepínače, místo aby je blokoval. Dejte je do profilu, ne do interaktivní příkazové řádky, jinak příští opětovné připojení funkční stav nezopakuje.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

Řádek DNS stojí v nepříjemné pozici: je to klientská direktiva, ale někteří klienti ji aplikují jen přes integraci DNS platformy, která ji může přepsat, když se spojení změní. Na hostiteli se systemd je nastavení resolveru přímo na rozhraní tunelu předvídatelnější než doufat, že klient vyhraje soutěž priorit:

resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.com

Doména směrování je stejně důležitá jako adresa. Bez ní se dotazy na veřejná jména mohou také posílat internímu resolveru a každý interní resolver, který odmítá rekurzi, rozbije prohlížení, zatímco soukromá zóna zůstane funkční. S ní se k resolveru tunelu směrují jen jména pod touto příponou a vše ostatní jde po fyzickém spojení.

Kontrola výsledku: adresa, jméno a vnější cesta

Tři testy oddělují možné poruchy. Získejte soukromou adresu přes IP, pak stejného hostitele podle jména, pak běžný veřejný web. Fungující IP s nefunkčním jménem ukazuje na resolver; nefunkční IP s fungujícím jménem ukazuje na směrování; obojí nefunkční obvykle znamená, že tunel není na cestě.

Pak se dívejte ven, ne dovnitř. Vlastní trasa koncového bodu tunelu musí změnu přežít a každé blokování poruchy musí být omezeno na tunel, aniž by zachytilo koncový bod. Klient, který po pádu tunelu dál prohlíží, je problém politiky, ne směrování, a v žádném ze tří testů výše se neprojeví.

Zapište konečný seznam do dokumentace profilu: trasy, resolver, domény a důvod, proč každý existuje. Opětovné připojení, které zopakuje stejnou tabulku, je jediným důkazem, že místní politika je úplná. Pokud aplikace stále selhávají se zvednutým tunelem a všemi třemi testy prošlými, dalším místem pohledu je třída problémů připojeno, ale offline, ne certifikáty, které už byly ověřeny.