FortiClienti täistunnel: suuna ainult kontori alamvõrku
VPN paigaldab vaikimisi marsruudi ja kohalik võrk kaob. Lugege tabelit, taastage LAN-i vaikimisi marsruut, lisage kontori prefiksid ja parandage seejärel DNS.
Tunnel tõuseb, ikoon muutub roheliseks ja kohalik võrk kaob: printerid, NAS ja kontori ruuter lakkavad vastamast. FortiClient teeb seda, mida profiil palus. Lüüs lükkas vaikimisi marsruudi, klient paigaldas selle ja igal paketil on nüüd tee tunnelisse. Parandus on marsruuditabeli muudatus ja selle taga DNS-i muudatus, ning nende muudatuste järjekord otsustab, kas masin pääseb sellest paremini või halvemini välja.
Mida klient paigaldas ja miks LAN kadus
Alustage tabeli lugemisest, mitte kliendi liidesest. macOS-is trükib netstat -rn kogu tabeli ja route -n get default nimetab liidese ja mõõdiku, mis praegu võidavad; Linuxis on paar ip route show ja ip route get 8.8.8.8. Mõlemad vastavad ühele küsimusele: milline kirje kannab paketti, mis ei vasta millelegi täpsemale.
Tunnelseadme nimi ei ole fikseeritud. IKEv2 profiil macOS-is näitab tavaliselt utun koos numbriga, SSL VPN klient näitab ppp0 ja OpenVPN näitab tun0. Samal ajal võib olla ka kaks vaikimisi marsruuti erinevate mõõdikutega ning kliendi kirje võib üle võtta alles pärast uuesti ühendamist, mitte ilmumise hetkel. Seetõttu võivad kaks viie minuti vahega tehtud tabeliväljavõtet rääkida erinevaid lugusid.
Miks tunneli vaikimisi marsruut peab esimesena kaduma
Kernel valib pikima sobiva prefiksi ja kui mitu marsruuti on võrdselt täpsed, valib madalaima mõõdikuga. Klient, mis paigaldab 0.0.0.0/0 parema mõõdikuga, võidab seetõttu iga sihtkoha ilma algset vaikimisi marsruuti kustutamata, ja seetõttu on füüsiline marsruut endiselt tabelis ja seletab endiselt katkestust. Tunneli vaikimisi marsruudi esimesena eemaldamine taastab varasema käitumise. Alles siis teeb prefiksimarsruut läbi tunneli seda, mida selle autor kavatses.
Prefiksite lisamine enne seda sammu on viga, mis annab pooleldi töötava masina. Uue prefiksi liiklus järgib tunnelit ja kõik loendis olev väljaspool olev järgib samuti tunneli vaikimisi marsruuti, nii et miski ei näe katki, kuni keegi avab teenuse, mida keegi ei lisanud. Kustutage, taastage, seejärel lisage, ja vahepealne olek jääb prognoositavaks.
Järjestus macOS-is ja Linuxis
macOS-is kustutab järjestus tunneli vaikimisi marsruudi, taastab füüsilise vaikimisi marsruudi ja saadab ühe kontori prefiksi tagasi tunnelisse. Asendage siinsed näidisliideste nimed oma tabeli omadega.
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 utun4Linuxis kasutab sama järjekord teist tööriista: LAN-i lüüs vaikimisi marsruudi jaoks ja tunnelseade kontori prefiksi jaoks. Vana käsk route võtab endiselt vastu vana süntaksi, kuid ip route on vorm, mis vastab praegusele dokumentatsioonile.
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 tun0Kui marsruut vajab seadme asemel järgmist hüpet, võtke peer kliendi väljundist. Oletamine annab ühe kahest veast ja need tähendavad erinevat: vale lüüs annab kohe network unreachable, vale tunnelisiht aga ajalõpu. Lugege, kumma saite, enne kui käsku uuesti muudate.
Prefiksid, resolver ja DMZ, mis jääb pimedaks
Üks prefiks katab töö harva. Rakendusserverid, haldusvõrgud, DMZ ja DNS-serverid ise võivad igaüks olla erinevas vahemikus, seega loetlege enne alustamist iga vahemik, mida suudate nimetada, ja testige päringut iga pingi kõrval. Testi keskel avastatud sihtkoht on see, mis muudatuste kirjes ununeb. Marsruut, mis vastab aadressi järgi, aga nurjub nime järgi, on tavaliselt resolveri probleem marsruutimise kostüümis.
Resolver on eraldi otsus. Kui profiil lükkas sisemised DNS-serverid, võib vaikimisi marsruudi äravõtmine jätta need aadressid avalike nimede jaoks kättesaamatuks või kättesaadavaks ainult tunneli kaudu, ja mõlemad olekud annavad segaseid osalisi tulemusi. Suunake resolveri aadressid läbi tunneli või seadistage domeenipõhine lahendus, et avalikud päringud kasutaksid kohalikku resolverit.
Linuxi SSL-kliendil on väljapõhine tõrge, mida tasub teada: tunnel ühendub, kontori LAN vastab ja üks DMZ vahemik jääb pimedaks. Puudu on marsruut selle vahemiku jaoks läbi tunneli lüüsi, ja lüüs erineb masinate vahel, seega kõvakodeeritud aadress on viis, kuidas järgmine sülearvuti katki läheb. Tuletage see kliendi olekust ja hoidke käsk isedokumenteerivana:
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"Lugege kaks väärtust enne selle käivitamist. peer on punkt-punkt-tunneli kaugem ots ja see on aadress, mida DMZ-i marsruut vajab; marsruuditud tunnelis on ekvivalent liides või lüüs, millest klient teatab. Kui kumbki ei ilmu, ei ole klient režiimis, mida eeldasite.
Pärast järgmist ühendust ja millal seda kohapeal lõpetada
FortiClient ühendub uuesti pärast und või võrgu muutust ja paigaldab uuesti selle, mida profiil ette näeb. Käsitsi marsruudid püsivad seetõttu ainult järgmise ühenduseni ja see on täpselt see intervall, mille jooksul üks õnnestunud test võib tunduda parandusena. Marsruut, mis öö jooksul kaob, on oodatud käitumine, mitte uus rike.
On kaks püsivat vastust. Skript, mis käivitab paranduse pärast igat ühendust, on ajutine lahendus, mis võib oma autorist kauem kesta, samas kui lüüsi administraatori poolitatud tunneli profiil on tegelik parandus, sest siis paigaldab klient ainult need vahemikud, mida töö vajab. Küsige teist ja kasutage esimest ainult oodates. Kontrollige ka poliitikat, millega nõustusite, enne kui jagate täistunneli kohapeal, sest kaugvõrk võib loota kogu teie liikluse nägemisele.
Kontrollnimekiri on lühike: lugege tabelit, kustutage tunneli vaikimisi marsruut, taastage LAN-i vaikimisi marsruut, lisage iga prefiks, parandage lahendus eraldi ja oodake, et marsruudid uuesti ühendamisel tagasi tulevad.