Cosa aggiunge davvero bypass-dhcp a un piano di rotte OpenVPN

Un profilo con redirect-gateway def1 bypass-dhcp combina una sostituzione della rotta IPv4 predefinita con un'unica eccezione ristretta. Le persone leggono l'ultima parola e si aspettano una soluzione generale per le connessioni mobili, poi passano un pomeriggio su una teoria DHCP che il flag non ha mai supportato. Ogni parte fa una cosa, e l'eccezione è molto più piccola della sua reputazione.

Separate i flag prima di attribuire un guasto solo mobile all'assegnazione degli indirizzi. Le due metà di quella stringa non hanno nulla a che vedere l'una con l'altra.

Due flag, due compiti senza relazione

Con def1, il client aggiunge due mezze rotte IPv4 predefinite invece di sostituire la rotta predefinita già presente. 0.0.0.0/1 copre la metà inferiore dello spazio di indirizzi e 128.0.0.0/1 quella superiore, così insieme raggiungono ogni destinazione mentre ciascuna resta più specifica di 0.0.0.0/0. La rotta predefinita originale resta quindi nella tabella senza vincere quelle ricerche, il che mantiene raggiungibile il vecchio gateway per tutto ciò che il client instrada esplicitamente. Lascia anche due rotte predefinite sovrapposte nella tabella, ed è per questo che un dump delle rotte può sembrare più strano di quanto suggerisca il profilo.

bypass-dhcp è separato e non tocca affatto la rotta predefinita. Il manuale di OpenVPN 2.6 lo documenta come l'aggiunta di una rotta diretta verso un server DHCP che non è sulla sottorete locale, così il traffico di lease esce fuori dal tunnel, e nota che il comportamento è implementato sui client Windows e potrebbe non essere disponibile altrove.

La ragione della sua esistenza è meccanica. Una volta che le mezze rotte predefinite catturano il traffico in uscita, un rinnovo DHCP diretto a un server sulla rete fisica verrebbe instradato nel tunnel a meno che qualcosa non fissi quell'indirizzo all'interfaccia reale. Il flag lo fissa.

A cosa è realmente limitata l'eccezione

Una tabella illustrativa dopo una connessione riuscita mostra la forma: due mezze rotte predefinite attraverso il tunnel e una rotta host per il server DHCP attraverso il gateway fisico. Leggetela come una forma, non come i vostri indirizzi.

0.0.0.0/1        via 10.8.0.1      dev tun0
128.0.0.0/1      via 10.8.0.1      dev tun0
192.168.1.1/32   via 192.168.1.254 dev wlan0

Quella terza riga nomina un'unica destinazione. Non è un'impostazione del resolver, non è un permesso generale per la rete locale e non è una regola di uscita sul server. Un telefono su un operatore mobile può non avere alcun server DHCP che il client possa identificare in questo modo, ed è per questo che il flag non cambia nulla lì.

Verificate cosa ha realmente installato il client

Distinguete un'opzione scritta in un profilo, un'opzione offerta dal server e una rotta che il proprietario della connessione ha realmente applicato. Un client che rifiuta un flag non supportato può conservare il resto della configurazione, quindi il tunnel si alza e l'eccezione è semplicemente assente. Leggete il registro del client stesso e la tabella di routing risultante invece di supporre che la riga nel file sia entrata in vigore. Tre di queste cose possono essere vere contemporaneamente, e solo l'ultima cambia dove vanno davvero i pacchetti.

Mantenete utilizzabile allo stesso tempo la rotta verso l'endpoint VPN. Quell'eccezione per l'endpoint è un requisito diverso dall'eccezione DHCP, e senza di essa il tunnel può catturare il trasporto che lo mantiene.

Per una destinazione applicativa, esaminate la ricerca effettiva nel contesto in cui fallisce. Rotte locali più specifiche, routing basato su policy ed esclusioni per applicazione cambiano tutte la risposta, quindi la presenza di due mezze rotte predefinite non è un inventario di ogni flusso.

Il resto del percorso non è in questo flag

Il server ha ancora bisogno del permesso di inoltrare il traffico internet del client e di una disposizione di uscita che possa restituirlo. Nessuna rotta lato client crea un inoltro o una traduzione di origine mancanti sul server, e nessun flag sostituisce un percorso di ritorno funzionante.

La risoluzione dei nomi e IPv6 hanno ciascuna bisogno della propria politica. Una sostituzione IPv4 non punta il resolver verso un server lato tunnel né stabilisce copertura IPv6, e un client che reindirizza solo v4 lascia intatto un percorso v6.

Confrontate una richiesta innocua approvata su un percorso di accesso funzionante e su uno guasto, mantenendo fissi profilo e destinazione. Annotate se la differenza sta nella risoluzione dei nomi, nella creazione del tunnel, nella scelta della rotta o nel traffico inoltrato, e conservate la risposta insieme al profilo. È quel registro che impedisce alla persona successiva di incolpare DHCP per un problema che non può raggiungere.