Routing VPN basato sul dominio o rotte IP: quale scegliere?

Una rotta IP corrisponde a un prefisso di indirizzo, e il kernel la applica senza fare altre domande. Una regola VPN basata sul dominio corrisponde a un nome, il che significa che qualcosa nello stack deve decidere quali indirizzi quel nome indica attualmente e mantenere aggiornata quella decisione. Sono meccanismi diversi con modi di guastarsi diversi, e i fornitori usano la stessa parola per entrambi. Confrontarli negli elenchi di funzioni manca il punto; confrontateli su cosa succede quando la risposta cambia.

La separazione utile è tra una regola che risolve e una regola che non risolve.

A cosa corrisponde davvero ogni regola

Una regola di prefisso corrisponde agli indirizzi di destinazione in una tabella di routing. Nulla viene risolto, nulla scade, e la corrispondenza è esatta per ogni pacchetto. Una regola di dominio corrisponde alla richiesta di un nome da parte di un'applicazione, che RFC 1034 definisce come un albero di etichette e non come un indirizzo. Alcuni prodotti risolvono il nome una volta e installano gli indirizzi risultanti come rotte, il che rende la regola una regola IP con un timer di aggiornamento allegato.

Sappiate quale dei due avete prima di fare debug, perché il guasto appare del tutto diverso in ciascun caso.

Dove vive la regola di dominio nello stack

Se il prodotto implementa le regole di dominio tramite un proxy locale, il traffico deve raggiungere quel proxy, e le applicazioni che ignorano il proxy di sistema aggirano del tutto la regola. Se le implementa risolvendo i nomi e aggiungendo rotte, gli indirizzi sono freschi solo fino all'ultimo aggiornamento. Se aggancia il resolver, il comportamento DNS diventa parte della politica di routing, e un resolver di riserva può annullarlo in silenzio.

Leggete il modello del fornitore invece dell'etichetta dell'impostazione. Due client con una casella chiamata Split Tunnel possono fare tre cose diverse.

Confrontate cosa si rompe

Tre cose si rompono in modi diversi. Rotazione degli indirizzi: un nome host CDN può risolversi in un insieme di indirizzi diverso nel giro di minuti, quindi un elenco copiato invecchia male. Ambito dei sottodomini: una regola per example.com può coprire api.example.com oppure no, e la documentazione di solito è esplicita su quale sia il caso. Guasto di risoluzione: quando il resolver fallisce, un client che risolve può ripiegare sul tunnelling del traffico o sull'invio diretto.

Solo la seconda è una questione di configurazione. Le altre due sono questioni di progetto su quanto il prodotto sia disposto a indovinare.

Quando il prefisso è la risposta migliore

Per una sottorete privata stabile, un prefisso esplicito è più chiaro, più veloce e più facile da verificare. Sopravvive anche a un guasto del resolver, perché nulla deve essere risolto. Ricorrete a una regola di dominio quando il servizio è ospitato, quando gli indirizzi ruotano o quando davvero non riuscite a enumerare l'insieme delle destinazioni. Non ricorretevi solo perché il nome host è ciò che conoscete per caso.

Un elenco statico indovinato è il peggio di entrambi: sembra mantenuto e manca il traffico in silenzio il giorno in cui il fornitore aggiunge un host.

Verificate con una richiesta nuova

Provate con una richiesta a freddo dopo una riconnessione normale, perché una pagina in cache potrebbe non toccare mai la regola. Risolvete il nome, poi controllate dove è andata davvero la connessione. dig +short app.example.com fornisce l'insieme di indirizzi attuale, e l'elenco delle connessioni del client vi dice quale interfaccia ha portato il flusso.

Ripetete dopo l'intervallo di aggiornamento documentato dal prodotto. Se l'insieme di indirizzi si sposta e la regola non lo segue, avete trovato il comportamento reale.

Tenete separata anche la politica del resolver. Una regola di dominio ha bisogno di dati di nome corretti, ma non decide da sola quale resolver risponde alla query.