FortiClient fuld tunnel: rut kun kontorets undernet

Tunnelen kommer op, ikonet bliver grønt, og det lokale netværk forsvinder: printere, NAS'en og kontorets router holder alle op med at svare. FortiClient gør det, profilen bad om. Gatewayen skubbede en standardrute, klienten installerede den, og hver pakke har nu en vej ind i tunnelen. Reparationen er en redigering af rutetabellen med en DNS-redigering bag sig, og rækkefølgen af de redigeringer afgør, om maskinen ender bedre eller værre.

Hvad klienten installerede, og hvorfor LAN'et forsvandt

Begynd med at læse tabellen i stedet for klientens grænseflade. På macOS udskriver netstat -rn hele tabellen, og route -n get default navngiver det interface og den metrik, der vinder lige nu; på Linux er parret ip route show og ip route get 8.8.8.8. Begge svarer på ét spørgsmål: hvilken post skal bære en pakke, der ikke matcher noget mere specifikt.

Tunneleenhedens navn er ikke fast. En IKEv2-profil på macOS viser normalt utun med et nummer, SSL VPN-klienten viser ppp0, og OpenVPN viser tun0. Der kan også være to standardruter samtidig med forskellige metrikker, og klientposten overtager måske først efter en genopkobling i stedet for i det øjeblik, den vises. Derfor kan to tabeludskrifter taget fem minutter fra hinanden fortælle forskellige historier.

Hvorfor tunnelens standardrute skal væk først

Kernen vælger det længste matchende præfiks, og når flere ruter er lige specifikke, vælger den den med den laveste metrik. En klient, der installerer 0.0.0.0/0 med en bedre metrik, vinder derfor hver destination uden at slette den oprindelige standardrute, og derfor er den fysiske rute stadig i tabellen og forklarer stadig afbrydelsen. At fjerne tunnelens standardrute først genskaber den tidligere adfærd. Først derefter gør en præfiksrute gennem tunnelen, hvad dens forfatter havde tænkt.

At tilføje præfikser før det trin er den fejl, der giver en halvt fungerende maskine. Trafik til det nye præfiks følger tunnelen, og alt, der ikke er på listen, følger også tunnelens standardrute, så intet ser ødelagt ud, før nogen åbner en tjeneste, ingen har tilføjet. Slet, genskab, tilføj derefter, og mellemtilstanden forbliver forudsigelig.

Rækkefølgen på macOS og på Linux

På macOS sletter rækkefølgen tunnelens standardrute, genskaber den fysiske standardrute og sender ét kontopræfiks tilbage i tunnelen. Erstat de illustrerende interfacenavne her med dem fra din egen tabel.

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 bruger samme orden et andet værktøj, med LAN-gatewayen til standardruten og tunneleenheden til kontopræfikset. Den gamle route-kommando accepterer stadig den gamle syntaks, men ip route er den form, der matcher den aktuelle dokumentation.

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 har brug for et næste hop i stedet for en enhed, tag peer fra klientens output. Gætteri giver en af to fejl, og de betyder forskellige ting: en forkert gateway giver network unreachable med det samme, mens et forkert tunnelmål giver en timeout. Læs, hvilken du fik, før du ændrer kommandoen igen.

Præfikser, resolveren og den DMZ, der bliver mørk

Ét præfiks dækker sjældent arbejdet. Applikationsservere, administrationsnetværk, DMZ'en og DNS-serverne selv kan hver ligge i et forskelligt interval, så list hvert interval, du kan navngive, før du starter, og test et opslag ved siden af hver ping. En destination, der opdages midt i testen, er den, der glemmes i ændringsloggen. En rute, der svarer på adresse men fejler på navn, er som regel et resolverproblem i rutekostume.

Resolveren er en separat beslutning. Når profilen har skubbet interne DNS-servere, kan fjernelsen af standardruten efterlade de adresser utilgængelige for offentlige navne eller kun tilgængelige gennem tunnelen, og begge tilstande giver forvirrende delresultater. Rut resolveradresserne gennem tunnelen, eller konfigurer opslag pr. domæne, så offentlige opslag bruger den lokale resolver.

Linux-SSL-klienten har en feltspecifik fejl, der er værd at kende: tunnelen forbinder, kontorets LAN svarer, og ét DMZ-interval forbliver mørkt. Den manglende brik er en rute til det interval gennem tunnelens gateway, og gatewayen er forskellig fra maskine til maskine, så en hårdkodet adresse er måden, den næste laptop går i stykker på. Udled 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"

Læs de to værdier, før du kører den. peer er den fjerne ende af en punkt-til-punkt-tunnel, og det er den adresse, DMZ-ruten har brug for; på en routet tunnel er ækvivalenten det interface eller den gateway, klienten rapporterer. Hvis ingen af dem vises, er klienten ikke i den tilstand, du antog.

Efter næste forbindelse, og hvornår du skal holde op med at gøre det lokalt

FortiClient genopkobler efter en dvale eller en netværksændring og geninstallerer det, profilen angiver. Manuelle ruter overlever derfor kun til næste forbindelse, og det er netop det interval, hvor en enkelt vellykket test kan se ud som en løsning. En rute, der forsvinder natten over, er forventet adfærd, ikke en ny fejl.

Der findes to holdbare svar. Et script, der kører rettelsen igen efter hver forbindelse, er en omvej, der kan overleve sin forfatter, mens en split-tunnel-profil fra gateway-administratoren er den egentlige løsning, fordi klienten så kun installerer de intervaller, arbejdet har brug for. Bed om det andet, og brug kun det første, mens du venter. Tjek også den politik, du har accepteret, før du splitter en fuld tunnel lokalt, fordi det fjernede netværk kan være afhængigt af at se al din trafik.

Tjeklisten er kort: læs tabellen, slet tunnelens standardrute, genskab LAN-standardruten, tilføj hvert præfiks, ret opslag separat, og forvent at ruterne vender tilbage ved genopkobling.