FortiClient full tunnel: routa bara kontorets subnät

Tunneln kommer upp, ikonen blir grön och det lokala nätverket försvinner: skrivare, NAS:en och kontorets router slutar alla svara. FortiClient gör det profilen bad om. Gatewayen sköt ut en standardrutt, klienten installerade den, och varje paket har nu en väg in i tunneln. Reparationen är en ändring i routingtabellen med en DNS-ändring bakom, och ordningen på dessa ändringar avgör om maskinen slutar bättre eller sämre.

Vad klienten installerade, och varför LAN:et försvann

Börja med att läsa tabellen i stället för klientens gränssnitt. På macOS skriver netstat -rn ut hela tabellen och route -n get default namnger det gränssnitt och den metrik som vinner just nu; på Linux är paret ip route show och ip route get 8.8.8.8. Båda svarar på en fråga: vilken post ska bära ett paket som inte matchar något mer specifikt.

Namnet på tunnelenheten är inte fast. En IKEv2-profil på macOS visar vanligtvis utun med ett nummer, SSL VPN-klienten visar ppp0, och OpenVPN visar tun0. Två standardrutter kan också finnas samtidigt med olika metriker, och klientposten tar kanske över först efter en återanslutning i stället för i samma stund som den dyker upp. Därför kan två tabellutskrifter tagna fem minuter isär berätta olika historier.

Varför tunnelns standardrutt måste bort först

Kärnan väljer det längsta matchande prefixet och när flera rutter är lika specifika väljer den den med lägst metrik. En klient som installerar 0.0.0.0/0 med bättre metrik vinner därför varje destination utan att radera den ursprungliga standardrutten, och därför står den fysiska rutten kvar i tabellen och förklarar fortfarande avbrottet. Att ta bort tunnelns standardrutt först återställer det tidigare beteendet. Först då gör en prefixrutt genom tunneln det som dess författare avsåg.

Att lägga till prefix före det steget är felet som ger en halvfungerande maskin. Trafiken för det nya prefixet följer tunneln, och allt som inte finns i listan följer också tunnelns standardrutt, så inget ser trasigt ut förrän någon öppnar en tjänst som ingen har lagt till. Radera, återställ och lägg sedan till, och mellanläget förblir förutsägbart.

Ordningen på macOS och på Linux

På macOS raderar ordningen tunnelns standardrutt, återställer den fysiska standardrutten och skickar ett kontorsprefix tillbaka in i tunneln. Byt ut de illustrativa gränssnittsnamnen här mot dem från din egen tabell.

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

På Linux använder samma ordning ett annat verktyg, med LAN-gatewayen för standardrutten och tunnelenheten för kontorsprefixet. Det gamla kommandot route accepterar fortfarande den gamla syntaxen, men ip route är den form som matchar den aktuella dokumentationen.

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

När rutten behöver ett nästa hopp i stället för en enhet, ta peer från klientens utdata. Gissningar ger ett av två fel, och de betyder olika saker: en felaktig gateway ger network unreachable direkt, medan ett felaktigt tunnelmål ger en timeout. Läs vilket du fick innan du ändrar kommandot igen.

Prefix, resolvern och den DMZ som blir mörk

Ett prefix täcker sällan hela arbetet. Applikationsservrar, administrationsnät, DMZ:en och DNS-servrarna själva kan var och en ligga i olika intervall, så lista varje intervall du kan namnge innan du börjar och testa en uppslagning bredvid varje ping. En destination som upptäcks mitt i testet är den som glöms bort i ändringsloggen. En rutt som svarar på adress men misslyckas på namn är oftast ett resolverproblem i routingkostym.

Resolvern är ett eget beslut. När profilen har skjutit ut interna DNS-servrar kan borttagandet av standardrutten lämna dessa adresser oåtkomliga för offentliga namn eller bara åtkomliga genom tunneln, och båda tillstånden ger förvirrande delresultat. Routa resolveradresserna genom tunneln, eller konfigurera uppslagning per domän så att offentliga uppslagningar använder den lokala resolvern.

Linux-SSL-klienten har ett fältspecifikt fel som är värt att känna till: tunneln ansluter, kontorets LAN svarar, och ett DMZ-intervall förblir mörkt. Den saknade biten är en rutt för det intervallet genom tunnelns gateway, och gatewayen skiljer sig mellan maskiner, så en hårdkodad adress är hur nästa laptop går sönder. Härled den från klientens tillstånd och håll kommandot självdokumenterande:

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"

Läs de två värdena innan du kör det. peer är den bortre änden av en punkt-till-punkt-tunnel, och det är adressen som DMZ-rutten behöver; på en routad tunnel är motsvarigheten det gränssnitt eller den gateway som klienten rapporterar. Om ingen av dem visas är klienten inte i det läge du antog.

Efter nästa anslutning, och när du bör sluta göra detta lokalt

FortiClient återansluter efter en viloläge eller en nätverksändring och installerar om det profilen anger. Manuella rutter överlever därför bara till nästa anslutning, och det är precis det intervall där ett enda lyckat test kan se ut som en lagning. En rutt som försvinner över natten är förväntat beteende, inte ett nytt fel.

Det finns två hållbara svar. Ett skript som kör rättelsen igen efter varje anslutning är en kringgång som kan överleva sin författare, medan en splitt-tunnel-profil från gateway-administratören är den egentliga rättelsen, eftersom klienten då bara installerar de intervall som arbetet behöver. Be om det andra och använd det första bara medan du väntar. Kontrollera också policyn du godkände innan du delar en full tunnel lokalt, eftersom det avlägsna nätverket kan vara beroende av att se all din trafik.

Checklistan är kort: läs tabellen, ta bort tunnelns standardrutt, återställ LAN-standardrutten, lägg till varje prefix, rätta uppslagningen separat, och räkna med att rutterna kommer tillbaka vid återanslutning.