FortiClient full tunnel: rut bare kontorunderenettet

Tunnelen kommer opp, ikonet blir grønt, og det lokale nettverket forsvinner: skrivere, NAS-en og kontoruteren slutter alle å svare. FortiClient gjør det profilen ba om. Gatewayen dyttet ut en standardrute, klienten installerte den, og hver pakke har nå en vei inn i tunnelen. Reparasjonen er en endring i rutetabellen med en DNS-endring bak, og rekkefølgen på disse endringene avgjør om maskinen ender bedre eller verre.

Hva klienten installerte, og hvorfor LAN-et forsvant

Begynn med å lese tabellen i stedet for klientgrensesnittet. På macOS skriver netstat -rn ut hele tabellen, og route -n get default navngir grensesnittet og metrikken som vinner akkurat nå; på Linux er paret ip route show og ip route get 8.8.8.8. Begge svarer på ett spørsmål: hvilken oppføring skal bære en pakke som ikke passer med noe mer spesifikt.

Navnet på tunneenheten er ikke fast. En IKEv2-profil på macOS viser vanligvis utun med et nummer, SSL VPN-klienten viser ppp0, og OpenVPN viser tun0. To standardruter kan også være til stede samtidig med ulike metrikker, og klientoppføringen overtar kanskje først etter en gjenoppkobling i stedet for i det øyeblikket den vises. Derfor kan to tabellutskrifter tatt fem minutter fra hverandre fortelle ulike historier.

Hvorfor tunnelens standardrute må bort først

Kjernen velger det lengste samsvarende prefikset, og når flere ruter er like spesifikke velger den den med lavest metrikk. En klient som installerer 0.0.0.0/0 med bedre metrikk vinner derfor hver destinasjon uten å slette den opprinnelige standardruten, og derfor står den fysiske ruten fortsatt i tabellen og forklarer fortsatt avbruddet. Å fjerne tunnelens standardrute først gjenoppretter den tidligere oppførselen. Først da gjør en prefiksrute gjennom tunnelen det forfatteren mente.

Å legge til prefikser før det trinnet er feilen som gir en halvfungerende maskin. Trafikken for det nye prefikset følger tunnelen, og alt som ikke er listet følger også tunnelens standardrute, så ingenting ser ødelagt ut før noen åpner en tjeneste ingen har lagt til. Slett, gjenopprett og legg deretter til, og mellomtilstanden forblir forutsigbar.

Rekkefølgen på macOS og på Linux

På macOS sletter rekkefølgen tunnelens standardrute, gjenoppretter den fysiske standardruten og sender ett kontorprefiks tilbake i tunnelen. Bytt ut de illustrerende grensesnittnavnene her med dem fra 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 bruker samme rekkefølge et annet verktøy, med LAN-gatewayen for standardruten og tunneenheten for kontorprefikset. Den gamle route-kommandoen godtar fortsatt den gamle syntaksen, men ip route er formen som passer med gjeldende 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 ruten trenger et neste hopp i stedet for en enhet, ta peer fra klientens utdata. Gjetting gir én av to feil, og de betyr forskjellige ting: en feil gateway gir network unreachable med en gang, mens et feil tunnelmål gir tidsavbrudd. Les hvilken du fikk før du endrer kommandoen igjen.

Prefikser, resolveren og DMZ-en som blir mørk

Ett prefiks dekker sjelden arbeidet. Applikasjonsservere, administrasjonsnettverk, DMZ-en og DNS-serverne selv kan hver ligge i et ulikt område, så list opp alle områdene du kan navngi før du begynner, og test et oppslag ved siden av hver ping. En destinasjon som oppdages midt i testen, er den som glemmes i endringsloggen. En rute som svarer på adresse men feiler på navn, er som regel et resolverproblem i rutekostyme.

Resolveren er en egen beslutning. Når profilen har dyttet ut interne DNS-servere, kan fjerningen av standardruten la disse adressene være utilgjengelige for offentlige navn eller bare tilgjengelige gjennom tunnelen, og begge tilstandene gir forvirrende delresultater. Rut resolveradressene gjennom tunnelen, eller konfigurer oppslag per domene slik at offentlige oppslag bruker den lokale resolveren.

Linux-SSL-klienten har en feltspesifikk feil det er verdt å kjenne: tunnelen kobler til, kontor-LAN-et svarer, og ett DMZ-område blir mørkt. Den manglende brikken er en rute for det området gjennom tunnelgatewayen, og gatewayen er ulik fra maskin til maskin, så en hardkodet adresse er måten den neste laptopen ryker på. Utled den fra klientens tilstand og hold kommandoen selvdokumenterende:

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 de to verdiene før du kjører den. peer er den fjerne enden av en punkt-til-punkt-tunnel, og det er adressen DMZ-ruten trenger; på en rutet tunnel er ekvivalenten grensesnittet eller gatewayen klienten rapporterer. Hvis ingen av dem vises, er ikke klienten i den modusen du antok.

Etter neste tilkobling, og når du bør slutte å gjøre dette lokalt

FortiClient kobler til på nytt etter dvale eller en nettverksendring og installerer på nytt det profilen angir. Manuelle ruter overlever derfor bare til neste tilkobling, og det er nettopp intervallet der én vellykket test kan se ut som en løsning. En rute som forsvinner over natten, er forventet oppførsel, ikke en ny feil.

Det finnes to varige svar. Et skript som kjører rettelsen på nytt etter hver tilkobling, er en omvei som kan overleve forfatteren sin, mens en splitt-tunnel-profil fra gateway-administratoren er den egentlige rettelsen, fordi klienten da bare installerer områdene arbeidet trenger. Be om det andre og bruk det første bare mens du venter. Sjekk også policyen du godtok før du splitter en full tunnel lokalt, fordi det eksterne nettverket kan være avhengig av å se all trafikken din.

Sjekklisten er kort: les tabellen, slett tunnelens standardrute, gjenopprett LAN-standardruten, legg til hvert prefiks, rett oppslaget separat, og forvent at rutene kommer tilbake ved gjenoppkobling.