Túnel complet de FortiClient: encamina només la subxarxa de l'oficina

El túnel s'aixeca, la icona es torna verda i la xarxa local desapareix: impressores, el NAS i el router de l'oficina deixen de respondre. FortiClient fa el que el perfil li ha demanat. La passarel·la ha empès una ruta per defecte, el client l'ha instal·lada i ara cada paquet té un camí cap al túnel. La reparació és una edició de la taula d'encaminament amb una edició de DNS al darrere, i l'ordre d'aquestes edicions decideix si la màquina acaba millor o pitjor.

Què ha instal·lat el client i per què ha desaparegut la LAN

Comença llegint la taula en comptes de la interfície del client. A macOS netstat -rn imprimeix tota la taula i route -n get default anomena la interfície i la mètrica que ara guanyen; a Linux la parella és ip route show i ip route get 8.8.8.8. Tots dos responen una pregunta: quina entrada portarà un paquet que no coincideix amb res més específic.

El nom del dispositiu del túnel no és fix. Un perfil IKEv2 a macOS normalment mostra utun amb un número, el client SSL VPN mostra ppp0 i OpenVPN mostra tun0. També poden ser presents dues rutes per defecte alhora amb mètriques diferents, i l'entrada del client pot prendre el relleu només després d'una reconnexió i no en el moment d'aparèixer. Per això dos bolcats de la taula separats per cinc minuts poden explicar històries diferents.

Per què la ruta per defecte del túnel ha de marxar primer

El nucli tria el prefix coincident més llarg i, quan diverses rutes són igual de específiques, tria la de mètrica més baixa. Per tant, un client que instal·la 0.0.0.0/0 amb una mètrica millor guanya cada destinació sense esborrar la ruta per defecte original, i per això la ruta física encara és a la taula i encara explica la caiguda. Treure primer la ruta per defecte del túnel restaura el comportament anterior. Només llavors una ruta de prefix pel túnel fa el que el seu autor volia.

Afegir prefixos abans d'aquest pas és l'error que produeix una màquina mig funcionant. El trànsit del prefix nou segueix el túnel, i tot el que no és a la llista també segueix la ruta per defecte del túnel, així que res no sembla trencat fins que algú obre un servei que ningú no ha afegit. Esborra, restaura i després afegeix, i l'estat intermedi es manté predictible.

La seqüència a macOS i a Linux

A macOS, la seqüència esborra la ruta per defecte del túnel, restaura la ruta per defecte física i torna a enviar un prefix de l'oficina cap al túnel. Substitueix els noms d'interfície il·lustratius d'aquí pels de la teva taula.

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

A Linux el mateix ordre fa servir una eina diferent: la passarel·la de la LAN per a la ruta per defecte i el dispositiu del túnel per al prefix de l'oficina. L'ordre antic route encara accepta la sintaxi vella, però ip route és la forma que coincideix amb la documentació actual.

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

Quan la ruta necessita un salt següent en comptes d'un dispositiu, pren el peer de la sortida del client. Endevinar produeix un de dos errors, i volen dir coses diferents: una passarel·la equivocada dóna network unreachable de seguida, mentre que un objectiu de túnel equivocat dóna un temps d'espera esgotat. Llegeix quin has obtingut abans de tornar a canviar l'ordre.

Prefixos, el resolutor i la DMZ que queda fosca

Un prefix poques vegades cobreix la feina. Els servidors d'aplicacions, les xarxes de gestió, la DMZ i els mateixos servidors DNS poden ser cadascun en un rang diferent, així que llista tots els rangs que puguis anomenar abans de començar i prova una consulta al costat de cada ping. Una destinació descoberta a mig test és la que s'oblida a la fitxa de canvis. Una ruta que respon per adreça però falla per nom sol ser un problema del resolutor amb vestit d'encaminament.

El resolutor és una decisió a part. Quan el perfil ha empès servidors DNS interns, treure la ruta per defecte pot deixar aquestes adreces inabastables per als noms públics o abastables només pel túnel, i tots dos estats produeixen resultats parcials confusos. Encamina les adreces del resolutor pel túnel, o configura la resolució per domini perquè les consultes públiques facin servir el resolutor local.

El client SSL de Linux té una fallada específica de camp que val la pena conèixer: el túnel connecta, la LAN de l'oficina respon i un rang de la DMZ queda fosc. La peça que falta és una ruta per a aquest rang a través de la passarel·la del túnel, i la passarel·la canvia entre màquines, així que una adreça codificada a mà és com es trenca el proper portàtil. Deriva-la de l'estat del client i mantén l'ordre 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"

Llegeix els dos valors abans d'executar-lo. peer és l'extrem llunyà d'un túnel punt a punt, que és l'adreça que necessita la ruta de la DMZ; en un túnel encaminat l'equivalent és la interfície o la passarel·la que informa el client. Si no apareix cap dels dos, el client no és en el mode que has suposat.

Després de la propera connexió i quan deixar-ho de fer en local

FortiClient es reconnecta després d'una dormida o d'un canvi de xarxa i torna a instal·lar el que especifica el perfil. Per tant, les rutes manuals només sobreviuen fins a la propera connexió, que és exactament l'interval en què una sola prova reeixida pot semblar una solució. Una ruta que desapareix de nit és el comportament esperat, no una fallada nova.

Hi ha dues respostes duradores. Un script que repeteix la correcció després de cada connexió és una solució provisional que pot sobreviure al seu autor, mentre que un perfil de túnel partit de l'administrador de la passarel·la és la solució real, perquè llavors el client només instal·la els rangs que necessita la feina. Demana la segona i fes servir la primera només mentre esperes. Comprova també la política que has acceptat abans de partir un túnel complet en local, perquè la xarxa remota pot dependre de veure tot el teu trànsit.

La llista de comprovació és curta: llegeix la taula, esborra la ruta per defecte del túnel, restaura la ruta per defecte de la LAN, afegeix cada prefix, arregla la resolució a part i espera que les rutes tornin en reconnectar.