Le rotte VPN Mac aggiuntive hanno bisogno di un proprietario, non di uno script di login

Raggiungere un prefisso privato tramite VPN è un requisito con una durata: vale finché quella connessione è utilizzabile e termina quando termina la connessione. Uno script di login non può esprimerlo, perché login e salita del tunnel sono momenti diversi, e il tunnel che esiste al login potrebbe non essere quello che trasporta traffico un minuto dopo. La prima decisione non è quale comando eseguire. È quale componente possiede il prefisso.

Il prefisso ha bisogno di un proprietario, non di un momento

Inizia scrivendo il requisito come frase con un soggetto: raggiungi 10.77.0.0/24 tramite la VPN dell'Ufficio finché quella connessione è attiva. Quella frase nomina il prefisso, la connessione e la condizione, e scarta subito due sostituti popolari: un hook di login e un nome di interfaccia come ppp0 o utun2.

I nomi delle interfacce vengono assegnati a runtime e non sono stabili tra riconnessioni. Un hook che corrisponde al nome visto la settimana scorsa o non scatta o scatta contro l'interfaccia di qualcun altro. Entrambi gli esiti si presentano come un bug di routing anziché come l'assunzione obsoleta che sono. La stessa obiezione vale per qualsiasi script legato a un nome che esiste solo finché un tunnel specifico è attivo.

Usa una fonte supportata di intenzione di rotta

Il gateway, un profilo gestito o il meccanismo di rotte documentato del client proprietario è il posto giusto, quando quel meccanismo può esprimere il requisito. Quale si applichi dipende dal protocollo e dal provider, e le chiavi non viaggiano tra loro, quindi un valore che configura un profilo OpenVPN non ti dice nulla sul client nativo L2TP o IKEv2.

Per chi sviluppa tunnel di pacchetti, le impostazioni del tunnel IPv4 di Apple espongono esplicitamente le rotte incluse ed escluse, e IPv6 ha la sua controparte. Sono API che il provider usa, non la prova che ogni pannello VPN nativo offra all'amministratore un elenco di rotte arbitrario. Se la combinazione attuale non riesce a esprimere i prefissi che ti servono, il passo successivo è un percorso di configurazione supportato dall'operatore, non un'altra app installata nella speranza che si comporti meglio.

La durata include la pulizia

A volte un helper esterno è davvero necessario, e quando lo è, «aggiungi la rotta» è la parte più piccola del suo lavoro. Deve sapere quale connessione serve e quale interfaccia usa quella connessione, attendere che lo stato di rete rilevante si assesti, restare idempotente quando viene eseguito due volte di seguito, e non pulire nulla che non abbia installato lui stesso.

L'ultima clausola è quella che fa male. Un helper che cancella ogni rotta corrispondente al prefisso dell'ufficio, prima o poi cancellerà una rotta che non ha aggiunto. L'interruzione che ne deriva viene attribuita al client VPN, perché il client è la parte che l'utente vede. Decidere cosa possiede un helper prima di scriverlo costa meno che spiegare dopo perché una sottorete locale ha smesso di rispondere.

La corsa alla riconnessione

Considera una riconnessione rapida. La sessione A cade, la sessione B sale e installa la sua rotta, e poi la pulizia ritardata di A finalmente parte. Se quella pulizia rimuove le rotte per prefisso, si porta via lo stato valido di B, e la connessione che funzionava un secondo fa ora instrada verso il nulla.

È una corsa di proprietà, e aggiungere un'attesa allo script cambia solo quale lato la vince. La soluzione è rendere la pulizia condizionata all'identità: confronta l'interfaccia e la sessione installate dall'helper con quelle ancora attuali, e rimuovi solo in caso di corrispondenza.

Cosa testare, e cosa una rotta non può fare

L'accettazione deve coprire quattro transizioni: la prima connessione, una riconnessione su un'interfaccia diversa, un tentativo di connessione fallito e la disconnessione finale. Dopo ciascuna, leggi la rotta che il sistema ha effettivamente scelto per un indirizzo sul lato remoto, non quella che ti aspettavi.

route -n get 10.77.0.5
netstat -rn -f inet

Includi i casi scomodi nella stessa passata: IPv6 dove serve, un prefisso locale che si sovrappone a quello remoto, e la rotta verso l'endpoint pubblico della VPN stesso, che deve continuare a funzionare finché il tunnel è attivo. Poi annota cosa una rotta non è. Seleziona i pacchetti; non concede permessi sul lato remoto e non crea un percorso di ritorno, e questi restano requisiti separati con proprietari separati.

Il risultato che vuoi è un prefisso che segue il suo proprietario di connessione supportato attraverso ogni transizione, non un comando che è riuscito una volta per caso sulla macchina dove è stato scritto.