Rotte persistenti per una VPN Mac: networksetup o un hook di connessione?

Una rotta digitata dopo ogni connessione risolve il momento e non la settimana. Su macOS la scelta duratura è di solito un prefisso memorizzato con il servizio VPN, perché il servizio lo reinstalla a ogni connessione e lo rimuove quando il servizio è inattivo. Le alternative sono un route add temporaneo per i test e un hook di connessione per indirizzi noti solo dopo la negoziazione.

Decidete se la rotta appartiene al servizio o alla sessione

Chiedete da cosa dipende il prefisso. Se è una rete privata fissa dietro un servizio VPN nativo, la rotta appartiene a quel servizio. Se dipende da un indirizzo peer che cambia a ogni connessione, un hook o un’attività guidata dallo stato possono essere il proprietario migliore. Se state solo controllando un percorso per i prossimi cinque minuti, una rotta temporanea basta.

La rotta legata al servizio ha il ciclo di vita più pulito. Appare con il servizio e scompare quando il servizio non è connesso, quindi non può sopravvivere al tunnel a cui punta. Questa proprietà vale più della comodità di un comando su una riga.

Una rotta legata alla sessione appartiene all’interfaccia, e quel numero cambia senza preavviso. Una riconnessione può dare al tunnel un nome utun diverso da quello usato dalla sessione precedente, il che trasforma un comando codificato in una rotta che non punta a nulla o, peggio, a un altro tunnel.

Leggete lo stato attuale della rotta e del servizio

Iniziate dai nomi che il sistema usa davvero. Il nome del servizio in Impostazioni di rete è l’identificatore per i comandi seguenti, e la tabella delle rotte attuale mostra cosa ha installato il client connesso. Leggete entrambi mentre il tunnel è attivo.

scutil --nc list
networksetup -listnetworkserviceorder
netstat -rn | head -30
route get 10.20.5.5

Quella ricerca mostra quale gateway e quale interfaccia il kernel sceglierebbe per questo indirizzo in questo momento. Se sceglie già il tunnel, il prefisso è coperto e una nuova rotta sarebbe ridondante. Se sceglie il router locale, al tunnel manca quel prefisso.

Annotate l’indirizzo peer mentre siete connessi. Diventa il valore del gateway nella rotta legata al servizio, ed è di solito la destinazione mostrata per la rotta predefinita del tunnel in netstat -rn.

Memorizzate il prefisso con networksetup

Lo strumento networksetup collega rotte aggiuntive a un servizio di rete. Per un servizio chiamato OfficeVPN e un prefisso privato raggiunto tramite il peer del tunnel, la forma è:

sudo networksetup -setadditionalroutes OfficeVPN 10.20.0.0 255.255.0.0 10.8.0.6
networksetup -getadditionalroutes OfficeVPN

Ogni terna dopo il nome del servizio dà una destinazione, la sua maschera di rete e il peer del tunnel come gateway. Una sola chiamata può portare più prefissi, e una chiamata vuota cancella l’elenco memorizzato. Il lettore è il passo di verifica; se l’elenco è vuoto, l’insieme non è stato applicato al servizio che credete.

Il gateway deve essere il peer del tunnel, non il router fisico. Una rotta che nomina il gateway locale manda il prefisso privato attraverso l’interfaccia fisica, che è il guasto originale con passaggi extra. Un peer obsoleto è la ragione più comune per cui una rotta dall’aspetto corretto non trasporta mai traffico. Rileggete il peer dallo stato connesso invece di copiare un indirizzo da una vecchia nota.

Usate route add solo per un test

Una rotta diretta è utile per dimostrare che un prefisso funziona prima di renderlo permanente. La forma con interfaccia evita una ricerca del gateway:

sudo route -n add -net 10.20.0.0/16 -interface utun4

La rotta svanisce alla prossima riconnessione e dipende dal numero di interfaccia che esiste oggi. Questo la rende una diagnostica, non un rilascio. Se il test funziona e la rotta legata al servizio no, confrontate prima il valore del gateway; è il campo più spesso sbagliato.

Attenzione ai consigli che sostituiscono la rotta predefinita della VPN per forzare la separazione. Un client che impone un tunnel completo può reinstallare le sue rotte dopo una riconnessione o un aggiornamento di policy, quindi la modifica manuale viene annullata in silenzio. Qualche prefisso privato è un problema di routing; tenere tutto il traffico internet locale contro una politica di tunnel completo è una decisione lato server.

Scegliete un hook solo quando l’indirizzo è negoziato

Per i collegamenti basati su PPP come L2TP, macOS esegue /etc/ppp/ip-up una volta stabilito il collegamento. Lo script riceve il nome dell’interfaccia e gli indirizzi locale e remoto negoziati, quindi può aggiungere una rotta che dipende dal peer assegnato dal server. È esattamente il caso che una rotta di servizio fissa non può esprimere.

IKEv2 e i client dei fornitori potrebbero non usare affatto quel percorso PPP, il che significa che lo script può restare silenzioso per tutta la sessione. Quando accade, un’attività launchd che interroga scutil --nc status e reagisce a un cambio di stato è il meccanismo equivalente, con un piccolo ritardo.

Qualunque hook usiate, rendetelo idempotente e fategli rimuovere solo le rotte che ha creato. Uno script che cancella ogni rotta che menziona il tunnel finirà per cancellare la rotta che tiene raggiungibile il server VPN, e la connessione cadrà appena riesce.

Terminate verificando la destinazione privata, la navigazione normale e un ciclo di riconnessione o sospensione. Poi ispezionate scutil --dns, perché la risoluzione dei nomi è una politica separata e una rotta funzionante non dimostra che i nomi privati si risolvano.