Plný tunel FortiClient: směrujte jen kancelářskou podsíť

Tunel se zvedne, ikona zezelená a místní síť zmizí: tiskárny, NAS i kancelářský router přestanou odpovídat. FortiClient dělá to, co profil požadoval. Brána poslala výchozí trasu, klient ji nainstaloval a každý paket má teď cestu do tunelu. Oprava je úprava směrovací tabulky a za ní úprava DNS, a pořadí těchto úprav rozhoduje, zda z toho stroj vyjde lépe, nebo hůř.

Co klient nainstaloval a proč LAN zmizela

Začněte čtením tabulky, ne rozhraním klienta. V macOS netstat -rn vypíše celou tabulku a route -n get default pojmenuje rozhraní a metriku, které právě vítězí; v Linuxu je dvojice ip route show a ip route get 8.8.8.8. Obě odpovídají na jednu otázku: který záznam ponese paket, jenž neodpovídá ničemu konkrétnějšímu.

Název tunelového zařízení není pevný. Profil IKEv2 v macOS obvykle ukazuje utun s číslem, klient SSL VPN ukazuje ppp0 a OpenVPN ukazuje tun0. Přítomné mohou být zároveň i dvě výchozí trasy s různými metrikami a klientský záznam se může ujmout až po opětovném připojení, ne v okamžiku, kdy se objeví. Proto dva výpisy tabulky pořízené pět minut po sobě mohou vyprávět různé příběhy.

Proč musí tunelová výchozí trasa odejít první

Jádro vybírá nejdelší odpovídající prefix a když je několik tras stejně konkrétních, vybere tu s nejnižší metrikou. Klient, který nainstaluje 0.0.0.0/0 s lepší metrikou, proto vyhraje každé cílové umístění, aniž by smazal původní výchozí trasu; právě proto je fyzická trasa stále v tabulce a stále vysvětluje výpadek. Odebrání tunelové výchozí trasy jako první obnoví předchozí chování. Teprve potom prefixová trasa tunelem dělá to, co její autor zamýšlel.

Přidání prefixů před tímto krokem je chyba, která vytvoří napůl fungující stroj. Provoz pro nový prefix jde tunelem a všechno neuvedené jde také tunelem přes výchozí trasu, takže nic nevypadá rozbité, dokud někdo neotevře službu, kterou nikdo nepřidal. Smažte, obnovte, potom přidejte a mezistav zůstane předvídatelný.

Pořadí v macOS a v Linuxu

V macOS pořadí smaže tunelovou výchozí trasu, obnoví fyzickou výchozí trasu a pošle jeden kancelářský prefix zpět do tunelu. Nahraďte ilustrativní názvy rozhraní zde těmi ze své tabulky.

sudo route delete -net default -interface utun4
sudo route add -net 0.0.0.0 -interface en0
sudo route add -net 10.20.0.0 -netmask 255.255.0.0 -interface utun4

V Linuxu stejné pořadí používá jiný nástroj: bránu LAN pro výchozí trasu a tunelové zařízení pro kancelářský prefix. Starý příkaz route stále přijímá starou syntaxi, ale ip route je forma, která odpovídá současné dokumentaci.

sudo ip route del default dev tun0
sudo ip route add default via 192.168.50.1
sudo ip route add 10.20.0.0/16 dev tun0

Když trasa potřebuje další skok místo zařízení, vezměte peer z výstupu klienta. Hádání dává jednu ze dvou chyb a ty znamenají různé věci: špatná brána dá okamžitě network unreachable, zatímco špatný cíl tunelu dá vypršení času. Přečtěte si, kterou jste dostali, než příkaz znovu změníte.

Prefixy, resolver a DMZ, která zůstává temná

Jeden prefix práci pokryje málokdy. Aplikační servery, správní sítě, DMZ i samotné servery DNS mohou být každý v jiném rozsahu, proto před začátkem vypište každý rozsah, který umíte pojmenovat, a u každého pingu otestujte dotaz. Cíl objevený během testu je ten, na který se v záznamu změn zapomene. Trasa, která odpovídá podle adresy, ale selhává podle jména, bývá problém resolveru v kostýmu směrování.

Resolver je samostatné rozhodnutí. Když profil poslal interní servery DNS, odebrání výchozí trasy může tyto adresy nechat nedostupné pro veřejná jména nebo dostupné jen tunelem, a oba stavy dávají matoucí částečné výsledky. Nasměrujte adresy resolveru tunelem, nebo nastavte překlad po doménách, aby veřejné dotazy používaly místní resolver.

Linuxový klient SSL má selhání specifické pro pole, které stojí za to znát: tunel se připojí, kancelářská LAN odpovídá a jeden rozsah DMZ zůstává temný. Chybějícím dílkem je trasa pro tento rozsah přes tunelovou bránu, a brána se mezi stroji liší, takže natvrdo zadaná adresa je způsob, jak se rozbije další notebook. Odvoďte ji ze stavu klienta a nechte příkaz samodokumentující:

PEER=$(ip -4 addr show dev ppp0 | awk '/peer/ {print $4}' | cut -d/ -f1)
sudo ip route add 192.168.30.0/24 via "$PEER"

Přečtěte si obě hodnoty, než jej spustíte. peer je vzdálený konec tunelu bod-bod, což je adresa, kterou trasa DMZ potřebuje; u směrovaného tunelu je ekvivalentem rozhraní nebo brána, kterou klient hlásí. Pokud se neobjeví ani jedno, klient není v režimu, který předpokládáte.

Po příštím připojení a kdy to místně přestat dělat

FortiClient se po spánku nebo změně sítě připojí znovu a znovu nainstaluje, co profil určuje. Ruční trasy proto přežijí jen do příštího připojení, což je přesně interval, ve kterém se jeden úspěšný test může jevit jako oprava. Trasa, která přes noc zmizí, je očekávané chování, ne nová závada.

Existují dvě trvalé odpovědi. Skript, který opravu spouští po každém připojení, je obchvat, který může přežít svého autora, zatímco profil s rozděleným tunelem od správce brány je skutečná oprava, protože pak klient instaluje jen rozsahy, které práce potřebuje. Žádejte druhé a první používejte jen během čekání. Před místním rozdělením plného tunelu si také zkontrolujte zásady, s nimiž jste souhlasili, protože vzdálená síť se může spoléhat na to, že vidí veškerý váš provoz.

Kontrolní seznam je krátký: přečtěte tabulku, smažte tunelovou výchozí trasu, obnovte výchozí trasu LAN, přidejte každý prefix, opravte překlad zvlášť a očekávejte, že se trasy při opětovném připojení vrátí.