Mantieni le rotte private e scarta il reindirizzamento: tunnel diviso OpenVPN

Il tunnel si alza, l’applicazione si carica, e poi tutto il resto sul portatile comincia a comportarsi in modo strano. È la forma abituale di una politica solo privata realizzata eliminando una riga. Rimuovere una rotta predefinita spinta cambia davvero dove va il traffico, ma non dice dove il traffico dovrebbe andare invece, e non tocca affatto la risoluzione dei nomi. Una politica ha bisogno di due metà positive prima di poter essere verificata.

Eliminare il reindirizzamento è solo metà della modifica

Un reindirizzamento a tunnel completo e una politica solo privata differiscono in ciò che affermano sul mondo. Il reindirizzamento rivendica ogni destinazione, mentre la politica privata rivendica un elenco e lascia il resto in pace. Eliminare la rivendicazione senza scrivere l’elenco produce un client che non raggiunge nulla fuori dalla LAN, il che sembra un guasto di instradamento più che una lacuna nella politica. Scrivi l’elenco prima di togliere la rivendicazione, e l’ordine di questi due passaggi smette di avere importanza.

Entrambe le metà sono requisiti, non valori predefiniti. I prefissi privati devono entrare nel tunnel, e le destinazioni ordinarie devono conservare il percorso che avevano prima della connessione.

Se un’organizzazione impone il tunnel completo, nulla di tutto ciò si applica. Il progetto solo privato appartiene alle distribuzioni in cui l’instradamento diviso è approvato.

pull-filter è una corrispondenza, non un interruttore

La direttiva pull-filter rimuove le opzioni spinte i cui nomi corrispondono a un prefisso, e questo è tutto ciò che fa. Ignorare il reindirizzamento lascia ogni altra opzione spinta al suo posto, che di solito è ciò che si vuole: rotte, impostazioni DNS e il valore del gateway di rotta arrivano comunque. Non può nemmeno rimuovere una direttiva scritta nel profilo locale, perché il filtraggio vale per ciò che il server spinge.

Resisti alla tentazione di ignorare ogni opzione che inizia con route. Quel modello scarta anche le rotte private di cui la connessione ha bisogno, e può far cadere informazioni sul gateway da cui dipende il tunnel.

route-nopull è una decisione più ampia di quanto sembri. Impedisce al client di accettare le rotte spinte e le opzioni in stile DHCP come gruppo, che è una politica diversa dal filtrare una sola opzione.

Scrivi l’elenco delle rotte dall’applicazione verso l’esterno

Parti da ciò che l’utente apre davvero, poi aggiungi le parti di supporto. Un’applicazione su 10.60.20.15 implica la sua sottorete 10.60.0.0/16, e un nome privato implica il resolver che gli risponde. Un utente che ha chiesto una sola applicazione ha quindi bisogno di due destinazioni e di una decisione DNS. Tutto ciò che va oltre quell’elenco è fuori ambito per costruzione, ed è ciò che mantiene la politica verificabile.

Su un server collaborativo quelle diventano due rotte spinte, e nessuna delle due è un reindirizzamento. Mantieni la topologia del tunnel e i valori del gateway di rotta forniti dal servizio esistente.

Quando solo alcuni utenti hanno bisogno di questa politica, applicala per client o per gruppo. Cambiare l’instradamento di tutti per correggere il requisito di un solo team è il modo in cui un tunnel diviso diventa un’interruzione.

Fai seguire lo stesso percorso al DNS

Una rotta verso il resolver non è una politica del resolver. Su un client systemd-resolved il risultato semantico è un dominio di instradamento per lo spazio dei nomi privato che punta al resolver interno, ed è ciò che fa usare solo quei nomi. Un client Windows ha invece bisogno del proprio meccanismo di politica degli spazi dei nomi. Una riga di server DNS nel profilo non installa nessuna delle due cose da sola.

Controlla ciò che il sistema operativo ha selezionato, non ciò che il profilo ha richiesto. Su Linux resolvectl status mostra il dominio e il server per collegamento; su Windows la tabella delle politiche degli spazi dei nomi è la prova equivalente.

Mantieni il resolver raggiungibile attraverso il tunnel, altrimenti la politica punta a un indirizzo che non può essere interrogato. Un indirizzo del resolver a cui il tunnel non arriva trasforma una politica funzionante in un timeout.

Verifica entrambe le metà a una riconnessione

Riconnetti il client dopo la modifica e ispeziona la rotta effettiva verso un indirizzo privato e verso uno pubblico. Poi risolvi un nome privato e un nome pubblico e conferma che ciascuno abbia usato il resolver previsto. Il caricamento di un sito pubblico dimostra solo la seconda metà, ed è la metà che di solito funziona per caso.

Registra la politica finita in una frase: questi prefissi e nomi usano questa connessione, tutto il resto segue il percorso locale. Poi tienila nel profilo invece di riparare le impostazioni della scheda dopo ogni accesso.