FortiClient-kokotunneli: reititä vain toimiston aliverkko

Tunneli nousee, kuvake muuttuu vihreäksi ja paikallinen verkko katoaa: tulostimet, NAS ja toimiston reititin lakkaavat kaikki vastaamasta. FortiClient tekee sen, mitä profiili pyysi. Yhdyskäytävä työnsi oletusreitin, asiakas asensi sen, ja jokaisella paketilla on nyt polku tunneliin. Korjaus on reititystaulukon muokkaus ja sen takana DNS-muokkaus, ja näiden muokkausten järjestys ratkaisee, jääkö kone parempaan vai huonompaan tilaan.

Mitä asiakas asensi ja miksi LAN katosi

Aloita lukemalla taulukko asiakkaan käyttöliittymän sijaan. macOSissa netstat -rn tulostaa koko taulukon ja route -n get default nimeää käyttöliittymän ja metriikan, jotka tällä hetkellä voittavat; Linuxissa pari on ip route show ja ip route get 8.8.8.8. Molemmat vastaavat yhteen kysymykseen: mikä merkintä kuljettaa paketin, joka ei vastaa mitään täsmällisempää.

Tunnelilaitteen nimi ei ole kiinteä. macOSin IKEv2-profiili näyttää yleensä utun numerolla, SSL VPN -asiakas näyttää ppp0 ja OpenVPN näyttää tun0. Kaksi oletusreittiä voi myös olla samanaikaisesti eri metriikoilla, ja asiakkaan merkintä voi ottaa vallan vasta yhteyden uudelleenmuodostuksen jälkeen eikä sinä hetkenä, jona se ilmestyy. Siksi kaksi viiden minuutin välein otettua taulukkavedosta voivat kertoa eri tarinoita.

Miksi tunnelin oletusreitin on lähdettävä ensin

Ydin valitsee pisimmän täsmäävän etuliitteen, ja kun useat reitit ovat yhtä täsmällisiä, se valitsee sen, jolla on pienin metriikka. Asiakas, joka asentaa 0.0.0.0/0 paremmalla metriikalla, voittaa siksi jokaisen kohteen poistamatta alkuperäistä oletusreittiä, ja siksi fyysinen reitti on yhä taulukossa ja selittää yhä katkoksen. Tunnelin oletusreitin poistaminen ensin palauttaa aiemman toiminnan. Vasta sen jälkeen tunnelin läpi kulkeva etuliitereitti tekee sen, mitä sen kirjoittaja tarkoitti.

Etuliitteiden lisääminen ennen sitä vaihetta on virhe, joka tuottaa puoliksi toimivan koneen. Uuden etuliitteen liikenne seuraa tunnelia, ja kaikki listaamaton seuraa myös tunnelin oletusreittiä, joten mikään ei näytä rikkinäiseltä ennen kuin joku avaa palvelun, jota kukaan ei lisännyt. Poista, palauta ja lisää sitten, ja välitila pysyy ennustettavana.

Järjestys macOSissa ja Linuxissa

macOSissa järjestys poistaa tunnelin oletusreitin, palauttaa fyysisen oletusreitin ja lähettää yhden toimiston etuliitteen takaisin tunneliin. Korvaa tässä olevat havainnolliset käyttöliittymien nimet omasta taulukostasi otetuilla.

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

Linuxissa sama järjestys käyttää toista työkalua: LANin yhdyskäytävä oletusreitille ja tunnelilaite toimiston etuliitteelle. Vanha route-komento hyväksyy yhä vanhan syntaksin, mutta ip route on muoto, joka vastaa nykyistä dokumentaatiota.

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

Kun reitti tarvitsee laitteen sijaan seuraavan hypyn, ota peer asiakkaan tulosteesta. Arvaaminen tuottaa toisen kahdesta virheestä, ja ne tarkoittavat eri asioita: väärä yhdyskäytävä antaa heti network unreachable, kun taas väärä tunnelikohde antaa aikakatkaisun. Lue, kumman sait, ennen kuin muutat komentoa uudelleen.

Etuliitteet, resolveri ja pimeänä pysyvä DMZ

Yksi etuliite kattaa työn harvoin. Sovelluspalvelimet, hallintaverkot, DMZ ja itse DNS-palvelimet voivat kukin olla eri alueella, joten luettele kaikki alueet, jotka osaat nimetä, ennen kuin aloitat, ja testaa haku jokaisen pingin rinnalla. Testin keskellä löytynyt kohde on se, joka muutoskirjauksessa unohtuu. Reitti, joka vastaa osoitteella mutta epäonnistuu nimellä, on yleensä resolverin ongelma reitityksen asussa.

Resolveri on erillinen päätös. Kun profiili on työntänyt sisäiset DNS-palvelimet, oletusreitin poistaminen voi jättää ne osoitteet julkisten nimien ulottumattomiin tai ulottuville vain tunnelin kautta, ja molemmat tilat tuottavat hämmentäviä osittaistuloksia. Reititä resolverin osoitteet tunnelin kautta tai määritä toimialuekohtainen ratkaisu, jotta julkiset haut käyttävät paikallista resolveria.

Linuxin SSL-asiakkaalla on kenttäkohtainen vika, joka kannattaa tuntea: tunneli yhdistyy, toimiston LAN vastaa ja yksi DMZ-alue jää pimeäksi. Puuttuva pala on reitti sille alueelle tunnelin yhdyskäytävän kautta, ja yhdyskäytävä vaihtelee koneiden välillä, joten kovakoodattu osoite on tapa, jolla seuraava kannettava hajoaa. Johda se asiakkaan tilasta ja pidä komento itsedokumentoivana:

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"

Lue kaksi arvoa ennen kuin suoritat sen. peer on pisteestä pisteeseen -tunnelin kauempi pää, ja se on osoite, jonka DMZ-reitti tarvitsee; reititetyssä tunnelissa vastine on käyttöliittymä tai yhdyskäytävä, jonka asiakas raportoi. Jos kumpikaan ei näy, asiakas ei ole siinä tilassa, jonka oletit.

Seuraavan yhteyden jälkeen ja milloin lopettaa tämä paikallisesti

FortiClient yhdistää uudelleen unen tai verkkoympäristön muutoksen jälkeen ja asentaa uudelleen sen, mitä profiili määrittää. Manuaaliset reitit säilyvät siksi vain seuraavaan yhteyteen, ja juuri se on väli, jossa yksi onnistunut testi voi näyttää korjaukselta. Yön aikana katoava reitti on odotettua toimintaa, ei uusi vika.

Kaksi kestävää vastausta on olemassa. Komentosarja, joka ajaa korjauksen uudelleen jokaisen yhteyden jälkeen, on kiertotie, joka voi elää kirjoittajaansa pidempään, kun taas yhdyskäytävän ylläpitäjän jaettu tunneliprofiili on varsinainen korjaus, koska silloin asiakas asentaa vain ne alueet, joita työ tarvitsee. Pyydä toista ja käytä ensimmäistä vain odottaessasi. Tarkista myös hyväksymäsi käytäntö ennen kuin jaat kokotunnelin paikallisesti, sillä etäverkko voi luottaa siihen, että se näkee kaiken liikenteesi.

Tarkistuslista on lyhyt: lue taulukko, poista tunnelin oletusreitti, palauta LANin oletusreitti, lisää jokainen etuliite, korjaa nimiratkaisu erikseen ja odota reittien palaavan uudelleenyhdistämisessä.