Tunel complet FortiClient: rutează doar subrețeaua biroului

Tunelul urcă, pictograma devine verde și rețeaua locală dispare: imprimantele, NAS-ul și routerul biroului nu mai răspund. FortiClient face ce a cerut profilul. Gateway-ul a împins o rută implicită, clientul a instalat-o, iar acum fiecare pachet are o cale în tunel. Reparația este o modificare a tabelului de rutare cu o modificare DNS în spate, iar ordinea acestor modificări decide dacă mașina iese mai bine sau mai rău.

Ce a instalat clientul și de ce a dispărut LAN-ul

Începe prin a citi tabelul în locul interfeței clientului. Pe macOS netstat -rn tipărește tot tabelul, iar route -n get default numește interfața și metrica ce câștigă acum; pe Linux perechea este ip route show și ip route get 8.8.8.8. Ambele răspund la o întrebare: care intrare va duce un pachet ce nu se potrivește cu nimic mai specific.

Numele dispozitivului tunelului nu este fix. Un profil IKEv2 pe macOS arată de obicei utun cu un număr, clientul SSL VPN arată ppp0, iar OpenVPN arată tun0. Pot exista și două rute implicite simultan, cu metrici diferite, iar intrarea clientului poate prelua controlul doar după o reconectare, nu în momentul în care apare. De aceea două capturi ale tabelului făcute la cinci minute distanță pot spune povești diferite.

De ce ruta implicită a tunelului trebuie să plece prima

Kernelul alege prefixul potrivit cel mai lung, iar când mai multe rute sunt la fel de specifice o alege pe cea cu metrica cea mai mică. Un client care instalează 0.0.0.0/0 cu o metrică mai bună câștigă deci fiecare destinație fără a șterge ruta implicită originală, și de aceea ruta fizică este încă în tabel și încă explică întreruperea. Scoaterea mai întâi a rutei implicite a tunelului restaurează comportamentul anterior. Abia apoi o rută de prefix prin tunel face ce a intenționat autorul ei.

Adăugarea prefixelor înainte de acel pas este greșeala care produce o mașină pe jumătate funcțională. Traficul pentru noul prefix urmează tunelul, iar tot ce nu este în listă urmează și el ruta implicită a tunelului, așa că nimic nu pare stricat până când cineva deschide un serviciu pe care nimeni nu l-a adăugat. Șterge, restaurează, apoi adaugă, iar starea intermediară rămâne previzibilă.

Secvența pe macOS și pe Linux

Pe macOS secvența șterge ruta implicită a tunelului, restaurează ruta implicită fizică și trimite un prefix al biroului înapoi în tunel. Înlocuiește numele de interfață ilustrative de aici cu cele din tabelul tău.

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

Pe Linux aceeași ordine folosește alt instrument: gateway-ul LAN pentru ruta implicită și dispozitivul tunelului pentru prefixul biroului. Comanda veche route acceptă încă sintaxa veche, dar ip route este forma care corespunde documentației actuale.

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

Când ruta are nevoie de un salt următor în loc de un dispozitiv, ia peer-ul din ieșirea clientului. Ghicitul produce una din două erori, iar ele înseamnă lucruri diferite: un gateway greșit dă imediat network unreachable, în timp ce o țintă de tunel greșită dă un timp limită. Citește care a apărut înainte de a schimba din nou comanda.

Prefixe, resolverul și DMZ-ul care rămâne întunecat

Un prefix acoperă rar toată munca. Serverele de aplicații, rețelele de administrare, DMZ-ul și serverele DNS înseși pot sta fiecare într-un interval diferit, așa că listează fiecare interval pe care îl poți numi înainte de a începe și testează o interogare lângă fiecare ping. O destinație descoperită la mijlocul testului este cea care se uită în registrul de modificări. O rută care răspunde pe adresă dar eșuează pe nume este de obicei o problemă a resolverului îmbrăcată în rutare.

Resolverul este o decizie separată. Când profilul a împins servere DNS interne, scoaterea rutei implicite poate lăsa acele adrese inaccesibile pentru nume publice sau accesibile doar prin tunel, iar ambele stări dau rezultate parțiale confuze. Rutează adresele resolverului prin tunel sau configurează rezolvarea pe domeniu, astfel încât interogările publice să folosească resolverul local.

Clientul SSL din Linux are o defecțiune specifică unui câmp pe care merită să o știi: tunelul se conectează, LAN-ul biroului răspunde, iar un interval DMZ rămâne întunecat. Piesa lipsă este o rută pentru acel interval prin gateway-ul tunelului, iar gateway-ul diferă de la o mașină la alta, așa că o adresă scrisă fix este modul în care se strică următorul laptop. Dedu-o din starea clientului și ține comanda autodocumentată:

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"

Citește cele două valori înainte de a o rula. peer este capătul îndepărtat al unui tunel punct-la-punct și este adresa de care are nevoie ruta DMZ; într-un tunel rutat echivalentul este interfața sau gateway-ul raportat de client. Dacă nu apare niciunul, clientul nu este în modul pe care l-ai presupus.

După următoarea conectare și când să nu mai faci asta local

FortiClient se reconectează după o suspendare sau o schimbare de rețea și reinstalează ce specifică profilul. Rutele manuale supraviețuiesc deci doar până la următoarea conectare, iar acesta este exact intervalul în care un singur test reușit poate părea o rezolvare. O rută care dispare peste noapte este comportament așteptat, nu o defecțiune nouă.

Există două răspunsuri durabile. Un script care rulează din nou corecția după fiecare conectare este o soluție de ocol care poate supraviețui autorului ei, în timp ce un profil de tunel divizat de la administratorul gateway-ului este rezolvarea reală, pentru că atunci clientul instalează doar intervalele de care are nevoie munca. Cere-l pe al doilea și folosește-l pe primul doar cât aștepți. Verifică și politica pe care ai acceptat-o înainte de a împărți local un tunel complet, pentru că rețeaua de la distanță se poate baza pe faptul că vede tot traficul tău.

Lista de verificare este scurtă: citește tabelul, șterge ruta implicită a tunelului, restaurează ruta implicită a LAN-ului, adaugă fiecare prefix, repară rezolvarea separat și așteaptă-te ca rutele să revină la reconectare.