Tunnel completo FortiClient: instradare solo la subnet dell'ufficio

Il tunnel si alza, l'icona diventa verde e la rete locale scompare: stampanti, il NAS e il router dell'ufficio smettono tutti di rispondere. FortiClient sta facendo ciò che il profilo ha chiesto. Il gateway ha spinto una rotta predefinita, il client l'ha installata, e ora ogni pacchetto ha un percorso dentro il tunnel. La riparazione è una modifica della tabella di routing con una modifica DNS dietro, e l'ordine di queste modifiche decide se la macchina finisce meglio o peggio.

Cosa ha installato il client e perché la LAN è sparita

Inizia leggendo la tabella invece dell'interfaccia del client. Su macOS netstat -rn stampa tutta la tabella e route -n get default indica l'interfaccia e la metrica che al momento vincono; su Linux la coppia è ip route show e ip route get 8.8.8.8. Entrambi rispondono a una domanda: quale voce porterà un pacchetto che non corrisponde a nulla di più specifico.

Il nome del dispositivo del tunnel non è fisso. Un profilo IKEv2 su macOS di solito mostra utun con un numero, il client SSL VPN mostra ppp0, e OpenVPN mostra tun0. Due rotte predefinite possono anche essere presenti contemporaneamente con metriche diverse, e la voce del client può subentrare solo dopo una riconnessione invece che nel momento in cui appare. Per questo due dump della tabella presi a cinque minuti di distanza possono raccontare storie diverse.

Perché la rotta predefinita del tunnel deve andarsene per prima

Il kernel sceglie il prefisso corrispondente più lungo e, quando più rotte sono ugualmente specifiche, sceglie quella con la metrica più bassa. Un client che installa 0.0.0.0/0 con una metrica migliore vince quindi ogni destinazione senza cancellare la rotta predefinita originale, ed è per questo che la rotta fisica è ancora nella tabella e spiega ancora il disservizio. Rimuovere prima la rotta predefinita del tunnel ripristina il comportamento precedente. Solo allora una rotta di prefisso attraverso il tunnel fa ciò che il suo autore intendeva.

Aggiungere prefissi prima di quel passaggio è l'errore che produce una macchina a metà. Il traffico per il nuovo prefisso segue il tunnel, e tutto ciò che non è elencato segue anch'esso la rotta predefinita del tunnel, quindi nulla sembra rotto finché qualcuno non apre un servizio che nessuno ha aggiunto. Elimina, ripristina, poi aggiungi, e lo stato intermedio resta prevedibile.

La sequenza su macOS e su Linux

Su macOS la sequenza elimina la rotta predefinita del tunnel, ripristina la rotta predefinita fisica e rimanda un prefisso dell'ufficio nel tunnel. Sostituisci i nomi di interfaccia illustrativi qui con quelli della tua tabella.

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

Su Linux lo stesso ordine usa un altro strumento: il gateway della LAN per la rotta predefinita e il dispositivo del tunnel per il prefisso dell'ufficio. Il vecchio comando route accetta ancora la sintassi vecchia, ma ip route è la forma che corrisponde alla documentazione attuale.

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

Quando la rotta ha bisogno di un salto successivo invece che di un dispositivo, prendi il peer dall'output del client. Indovinare produce uno di due errori, e significano cose diverse: un gateway sbagliato dà network unreachable subito, mentre un target del tunnel sbagliato dà un timeout. Leggi quale hai ottenuto prima di cambiare di nuovo il comando.

Prefissi, il resolver e la DMZ che resta buia

Un prefisso raramente copre il lavoro. I server applicativi, le reti di gestione, la DMZ e i server DNS stessi possono stare ciascuno in un intervallo diverso, quindi elenca ogni intervallo che riesci a nominare prima di iniziare e prova una risoluzione accanto a ogni ping. Una destinazione scoperta a metà test è quella che viene dimenticata nel registro delle modifiche. Una rotta che risponde per indirizzo ma fallisce per nome è di solito un problema del resolver vestito da routing.

Il resolver è una decisione separata. Quando il profilo ha spinto server DNS interni, togliere la rotta predefinita può lasciare quegli indirizzi irraggiungibili per i nomi pubblici o raggiungibili solo attraverso il tunnel, ed entrambi gli stati producono risultati parziali confusi. Instrada gli indirizzi del resolver attraverso il tunnel, oppure configura la risoluzione per dominio in modo che le ricerche pubbliche usino il resolver locale.

Il client SSL Linux ha un guasto specifico di un campo che vale la pena conoscere: il tunnel si connette, la LAN dell'ufficio risponde, e un intervallo della DMZ resta buio. Il pezzo mancante è una rotta per quell'intervallo attraverso il gateway del tunnel, e il gateway cambia da macchina a macchina, quindi un indirizzo codificato a mano è il modo in cui si rompe il portatile successivo. Derivala dallo stato del client e mantieni il comando autodocumentato:

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"

Leggi i due valori prima di eseguirlo. peer è l'estremità remota di un tunnel punto a punto, ed è l'indirizzo che serve alla rotta della DMZ; su un tunnel instradato l'equivalente è l'interfaccia o il gateway che il client riporta. Se non compare nessuno dei due, il client non è nella modalità che hai supposto.

Dopo la prossima connessione, e quando smettere di farlo in locale

FortiClient si riconnette dopo una sospensione o un cambio di rete e reinstalla ciò che il profilo specifica. Le rotte manuali quindi sopravvivono solo fino alla connessione successiva, che è esattamente l'intervallo in cui un singolo test riuscito può sembrare una correzione. Una rotta che scompare durante la notte è un comportamento atteso, non un nuovo guasto.

Esistono due risposte durature. Uno script che riesegue la correzione dopo ogni connessione è un aggiramento che può sopravvivere al suo autore, mentre un profilo di tunnel diviso dall'amministratore del gateway è la correzione vera, perché allora il client installa solo gli intervalli che il lavoro richiede. Chiedi il secondo e usa il primo solo durante l'attesa. Controlla anche la policy che hai accettato prima di dividere un tunnel completo in locale, perché la rete remota può contare sul vedere tutto il tuo traffico.

La lista di controllo è breve: leggi la tabella, elimina la rotta predefinita del tunnel, ripristina la rotta predefinita della LAN, aggiungi ogni prefisso, correggi la risoluzione a parte, e aspettati che le rotte tornino alla riconnessione.