FortiClient polni tunel: usmerite samo pisarniško podomrežje
VPN namesti privzeto pot in lokalno omrežje izgine. Preberite tabelo, obnovite privzeto pot LAN, dodajte pisarniške predpone in nato popravite DNS.
Tunel se dvigne, ikona postane zelena in lokalno omrežje izgine: tiskalniki, NAS in pisarniški usmerjevalnik prenehajo odgovarjati. FortiClient dela tisto, kar je zahteval profil. Prehod je poslal privzeto pot, odjemalec jo je namestil in vsak paket ima zdaj pot v tunel. Popravilo je sprememba tabele poti s spremembo DNS za njo, in vrstni red teh sprememb odloči, ali bo stroj končal bolje ali slabše.
Kaj je odjemalec namestil in zakaj je LAN izginil
Začnite z branjem tabele namesto vmesnika odjemalca. V macOS netstat -rn izpiše celotno tabelo, route -n get default pa poimenuje vmesnik in metriko, ki trenutno zmagujeta; v Linuxu je par ip route show in ip route get 8.8.8.8. Oba odgovarjata na eno vprašanje: kateri vnos bo nosil paket, ki se ne ujema z ničimer bolj določenim.
Ime tunelske naprave ni fiksno. Profil IKEv2 v macOS običajno prikazuje utun s številko, odjemalec SSL VPN prikazuje ppp0, OpenVPN pa tun0. Dve privzeti poti sta lahko hkrati prisotni z različnima metrikama, vnos odjemalca pa lahko prevzame nadzor šele po ponovni povezavi in ne v trenutku, ko se pojavi. Zato lahko dva izpisa tabele s petminutnim razmakom pripovedujeta različni zgodbi.
Zakaj mora tunelska privzeta pot oditi prva
Jedro izbere najdaljšo ujemajočo se predpono, kadar pa je več poti enako določenih, izbere tisto z najnižjo metriko. Odjemalec, ki namesti 0.0.0.0/0 z boljšo metriko, zato zmaga na vsaki destinaciji brez brisanja prvotne privzete poti, in zato je fizična pot še vedno v tabeli in še vedno pojasnjuje izpad. Odstranitev tunelske privzete poti najprej obnovi prejšnje vedenje. Šele nato predponska pot skozi tunel naredi tisto, kar je njen avtor nameraval.
Dodajanje predpon pred tem korakom je napaka, ki da napol delujoč stroj. Promet za novo predpono sledi tunelu in vse, kar ni na seznamu, prav tako sledi tunelski privzeti poti, zato nič ne izgleda pokvarjeno, dokler nekdo ne odpre storitve, ki je nihče ni dodal. Izbrišite, obnovite in nato dodajte, vmesno stanje pa ostane predvidljivo.
Zaporedje v macOS in v Linuxu
V macOS zaporedje izbriše tunelsko privzeto pot, obnovi fizično privzeto pot in pošlje eno pisarniško predpono nazaj v tunel. Zamenjajte tu navedena ponazoritvena imena vmesnikov s tistimi iz svoje tabele.
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 utun4V Linuxu isto zaporedje uporablja drugo orodje: prehod LAN za privzeto pot in tunelsko napravo za pisarniško predpono. Stari ukaz route še vedno sprejema staro sintakso, vendar je ip route oblika, ki ustreza trenutni dokumentaciji.
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 tun0Ko pot potrebuje naslednji skok namesto naprave, vzemite peer iz izhoda odjemalca. Ugibanje da eno od dveh napak in ti pomenita različno: napačen prehod takoj da network unreachable, napačen cilj tunela pa časovno prekoračitev. Preberite, katero ste dobili, preden ukaz znova spremenite.
Predpone, razreševalnik in DMZ, ki ostane temen
Ena predpona redko pokrije delo. Aplikacijski strežniki, upravljalna omrežja, DMZ in sami strežniki DNS so lahko vsak v drugem obsegu, zato pred začetkom naštejte vsak obseg, ki ga znate poimenovati, in ob vsakem ping preizkusite poizvedbo. Cilj, odkrit med preizkusom, je tisti, ki se v zapisu sprememb pozabi. Pot, ki odgovarja po naslovu, a odpove po imenu, je običajno težava razreševalnika v kostumu usmerjanja.
Razreševalnik je ločena odločitev. Ko je profil poslal notranje strežnike DNS, lahko odvzem privzete poti te naslove pusti nedosegljive za javna imena ali dosegljive le skozi tunel, oba stanja pa dajeta zmedene delne rezultate. Usmerite naslove razreševalnika skozi tunel ali nastavite razreševanje po domenah, da javne poizvedbe uporabljajo lokalni razreševalnik.
Odjemalec SSL v Linuxu ima napako, značilno za polje, ki jo velja poznati: tunel se poveže, pisarniški LAN odgovarja, en obseg DMZ pa ostane temen. Manjkajoči del je pot za ta obseg skozi tunelski prehod, prehod pa se med stroji razlikuje, zato je trdo kodiran naslov način, kako se zlomi naslednji prenosnik. Izpeljite jo iz stanja odjemalca in ukaz ohranite samodokumentiran:
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"Preberite obe vrednosti, preden ga zaženete. peer je oddaljeni konec tunela od točke do točke in to je naslov, ki ga potrebuje pot DMZ; pri usmerjenem tunelu je enakovredni vmesnik ali prehod, ki ga odjemalec poroča. Če se ne pokaže nobeno, odjemalec ni v načinu, ki ste ga predpostavili.
Po naslednji povezavi in kdaj to prenehati početi lokalno
FortiClient se po mirovanju ali spremembi omrežja znova poveže in znova namesti, kar določa profil. Ročne poti zato preživijo le do naslednje povezave, in to je natanko interval, v katerem je lahko en sam uspešen preizkus videti kot popravilo. Pot, ki čez noč izgine, je pričakovano vedenje, ne nova okvara.
Obstajata dva trajna odgovora. Skript, ki popravek znova zažene po vsaki povezavi, je obhod, ki lahko preživi svojega avtorja, medtem ko je profil z razdeljenim tunelom od skrbnika prehoda pravo popravilo, ker odjemalec takrat namesti le obsege, ki jih delo potrebuje. Zahtevajte drugo in prvo uporabljajte le med čakanjem. Pred lokalno razdelitvijo polnega tunela preverite tudi pravilnik, s katerim ste se strinjali, ker se oddaljeno omrežje morda zanaša na to, da vidi ves vaš promet.
Kontrolni seznam je kratek: preberite tabelo, izbrišite tunelsko privzeto pot, obnovite privzeto pot LAN, dodajte vsako predpono, ločeno popravite razreševanje in pričakujte, da se poti ob ponovni povezavi vrnejo.