FortiClient full tunnel: rut berre kontorunderenettet

Tunnelen kjem opp, ikonet vert grønt, og det lokale nettet forsvinn: skrivarar, NAS-en og kontoruteren sluttar alle å svare. FortiClient gjer det profilen bad om. Gatewayen dytta ut ei standardrute, klienten installerte ho, og kvar pakke har no ein veg inn i tunnelen. Reparasjonen er ei endring i rutetabellen med ei DNS-endring bak, og rekkjefølgja på desse endringane avgjer om maskina endar betre eller verre.

Kva klienten installerte, og kvifor LAN-et forsvann

Byrja med å lese tabellen i staden for klientgrensesnittet. På macOS skriv netstat -rn ut heile tabellen, og route -n get default namngjev grensesnittet og metrikken som vinn akkurat no; på Linux er paret ip route show og ip route get 8.8.8.8. Begge svarar på eitt spørsmål: kva oppføring skal bere ein pakke som ikkje passar med noko meir spesifikt.

Namnet på tunneininga er ikkje fast. Ein IKEv2-profil på macOS viser vanlegvis utun med eit nummer, SSL VPN-klienten viser ppp0, og OpenVPN viser tun0. To standardruter kan òg vere til stades samstundes med ulike metrikkar, og klientoppføringa overtek kanskje fyrst etter ei ny tilkopling i staden for i det augneblinken ho viser seg. Derfor kan to tabellutskrifter tekne fem minutt frå kvarandre fortelje ulike historier.

Kvifor standardruta til tunnelen må bort fyrst

Kjernen vel det lengste samsvarande prefikset, og når fleire ruter er like spesifikke vel han den med lågast metrikk. Ein klient som installerer 0.0.0.0/0 med betre metrikk vinn derfor kvar destinasjon utan å slette den opphavlege standardruta, og derfor står den fysiske ruta framleis i tabellen og forklarer framleis avbrotet. Å fjerne standardruta til tunnelen fyrst gjenopprettar den tidlegare åtferda. Fyrst då gjer ei prefiksrute gjennom tunnelen det forfattaren meinte.

Å leggje til prefiks før det trinnet er feilen som gjev ei halvfungerande maskin. Trafikken for det nye prefikset følgjer tunnelen, og alt som ikkje er lista følgjer òg standardruta til tunnelen, så ingenting ser øydelagt ut før nokon opnar ei teneste ingen har lagt til. Slett, gjenopprett og legg deretter til, og mellomtilstanden held seg føreseieleg.

Rekkjefølgja på macOS og på Linux

På macOS slettar rekkjefølgja standardruta til tunnelen, gjenopprettar den fysiske standardruta og sender eitt kontorprefiks tilbake i tunnelen. Bytt ut dei illustrerande grensesnittnamna her med dei frå din eigen 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 brukar same rekkjefølgja eit anna verktøy, med LAN-gatewayen for standardruta og tunneininga for kontorprefikset. Den gamle route-kommandoen godtek framleis den gamle syntaksen, men ip route er forma som passar med gjeldande dokumentasjon.

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 ruta treng eit neste hopp i staden for ei eining, ta peer frå utdataa til klienten. Gjetting gjev éin av to feil, og dei tyder ulike ting: ein feil gateway gjev network unreachable med ein gong, medan eit feil tunnelmål gjev tidsavbrot. Les kva du fekk før du endrar kommandoen igjen.

Prefiks, resolveren og DMZ-en som vert mørk

Eitt prefiks dekkjer sjeldan arbeidet. Applikasjonsservarar, administrasjonsnettverk, DMZ-en og DNS-servarane sjølve kan kvar liggje i eit ulikt område, så list opp alle områda du kan namngje før du byrjar, og test eit oppslag ved sida av kvar ping. Ein destinasjon som vert oppdaga midt i testen, er den som vert gløymd i endringsloggen. Ei rute som svarar på adresse men feilar på namn, er som regel eit resolverproblem i rutekostyme.

Resolveren er ei eiga avgjerd. Når profilen har dytta ut interne DNS-servarar, kan fjerninga av standardruta la desse adressene vere utilgjengelege for offentlege namn eller berre tilgjengelege gjennom tunnelen, og begge tilstandane gjev forvirrande delresultat. Rut resolveradressene gjennom tunnelen, eller konfigurer oppslag per domene slik at offentlege oppslag brukar den lokale resolveren.

Linux-SSL-klienten har ein feltspesifikk feil det er verdt å kjenne: tunnelen koplar til, kontor-LAN-et svarar, og eitt DMZ-område vert mørkt. Den manglande brikka er ei rute for det området gjennom tunnelgatewayen, og gatewayen er ulik frå maskin til maskin, så ei hardkoda adresse er måten den neste berbare maskina ryker på. Leid ho ut frå tilstanden til klienten og hald kommandoen 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"

Les dei to verdiane før du køyrer han. peer er den fjerne enden av ein punkt-til-punkt-tunnel, og det er adressa DMZ-ruta treng; på ein ruta tunnel er ekvivalenten grensesnittet eller gatewayen klienten rapporterer. Viss ingen av dei viser seg, er ikkje klienten i den modusen du antok.

Etter neste tilkopling, og når du bør slutte å gjere dette lokalt

FortiClient koplar til på nytt etter dvale eller ei nettverksendring og installerer på nytt det profilen angjev. Manuelle ruter overlever derfor berre til neste tilkopling, og det er nettopp intervallet der éin vellukka test kan sjå ut som ei løysing. Ei rute som forsvinn over natta, er forventa åtferd, ikkje ein ny feil.

Det finst to varige svar. Eit skript som køyrer rettinga på nytt etter kvar tilkopling, er ein omveg som kan overleve forfattaren sin, medan ein splitt-tunnel-profil frå gateway-administratoren er den eigentlege rettinga, fordi klienten då berre installerer områda arbeidet treng. Be om det andre og bruk det fyrste berre medan du ventar. Sjekk òg policyen du godtok før du splittar ein full tunnel lokalt, fordi det eksterne nettverket kan vere avhengig av å sjå all trafikken din.

Sjekklista er kort: les tabellen, slett standardruta til tunnelen, gjenopprett LAN-standardruta, legg til kvart prefiks, rett oppslaget separat, og vent at rutene kjem tilbake ved ny tilkopling.