Perché un carattere jolly in una direttiva route di OpenVPN non può funzionare

la route installa prefissi di indirizzo, quindi un modello di nome host non ha nulla con cui corrispondere. Usate un prefisso per le reti e un proxy o un file PAC quando devono decidere i domini.

L’intenzione è ragionevole: inviare tutto ciò che riguarda un dominio aziendale attraverso il tunnel e lasciare il resto in pace. La direttiva che viene modificata installa route, e una route non ha alcun concetto di nome host con cui corrispondere. Ogni tentativo di scrivervi un carattere jolly produce o un errore di analisi o, peggio, una route che oggi funziona per caso perché il nome si è risolto in un solo indirizzo. Si chiede a due meccanismi diversi di fare il lavoro dell’altro.

Cosa installa una route e cosa non legge mai

Una voce di route afferma che un prefisso di destinazione è raggiungibile attraverso un’interfaccia. Il kernel confronta i pacchetti con quei prefissi, quindi gli unici identificatori coinvolti sono indirizzi e maschere. Un nome host non compare mai nella decisione di inoltro, ed è per questo che lì non si può confrontare alcun modello.

OpenVPN può accettare un nome risolvibile in alcuni parametri di route, e questa tolleranza è una fonte di confusione. Il nome viene risolto mentre viene applicata la configurazione, producendo uno o più indirizzi che diventano route ordinarie. Dopo di che, il nome scompare del tutto dall’immagine.

Quindi una route costruita da un nome è un’istantanea, non una regola. Copre ciò a cui quel nome si è risolto nel momento in cui è partito il tunnel, ed è esattamente il comportamento che non volete per una famiglia di host che cambia. Un record che si sposta domani lascia la route puntata a ieri.

Quando la destinazione è davvero un prefisso

Se l’obiettivo è una rete privata nota, scrivete il prefisso. Per un esempio dello spazio di documentazione, un singolo host e una sottorete appaiono così:

route 10.60.4.20 255.255.255.255
route 10.60.0.0 255.255.0.0

Entrambe le voci nominano indirizzi e maschere, ed entrambe sopravvivono ai cambiamenti DNS perché nulla in esse dipende da un nome. È tutto il vantaggio: la route è un’affermazione sulla topologia e non su una ricerca avvenuta una volta.

Non estrapolate un prefisso grande da una singola risposta DNS. Un nome host che si risolve in un indirizzo non vi dice nulla sulla dimensione della rete dietro di esso, e un prefisso indovinato è il modo in cui un tunnel finisce per catturare traffico che nessuno intendeva inviare attraverso di esso. Chiedete il prefisso reale al proprietario della rete invece di dedurlo da una ricerca.

Quando l’unità di lavoro è un nome host

Selezionare per dominio richiede qualcosa che legga il dominio, cioè un componente a livello applicativo. La risposta abituale è un proxy HTTP che vive dall’altra parte del tunnel, con il client che sceglie quali richieste inviargli.

Un file di configurazione del proxy può esprimere questa scelta. Le regole illustrative qui sotto inviano un dominio e i suoi sottodomini a un proxy e tutto il resto diretto:

function FindProxyForURL(url, host) {
    var h = host.toLowerCase();
    if (h === "corp.example" || dnsDomainIs(h, ".corp.example")) {
        return "PROXY 10.60.0.12:3128";
    }
    return "DIRECT";
}

Il confronto del nome esatto copre il dominio stesso, e il confronto del suffisso copre i suoi figli senza corrispondere a un nome che termina semplicemente con caratteri simili. Entrambi sono necessari, e ometterne uno produce una regola che sembra corretta e salta l’apice o un impostore.

Queste regole scelgono un proxy; non ne creano uno e non cambiano alcuna route del sistema operativo. L’indirizzo del proxy ha ancora bisogno del proprio percorso attraverso il tunnel, e le richieste contrassegnate come dirette seguono comunque la politica di routing che la macchina ha già.

Cosa non copre l’opzione proxy

I programmi che ignorano la configurazione proxy del browser non saranno influenzati da nulla di tutto questo. Gli strumenti da riga di comando, gli aggiornatori e le applicazioni con il proprio stack di rete prendono la tabella di routing, non il file PAC, quindi quei casi richiedono un meccanismo per singola applicazione supportato o un’altra progettazione. Fate l’inventario dei client che contano prima di promettere che la regola del browser copra il flusso di lavoro.

Tornare diretti non è nemmeno una via di fuga. Se la politica di routing della macchina invia già tutto nel tunnel, una richiesta contrassegnata come diretta resta al suo interno, perché la scelta del proxy e la tabella di routing sono decisioni diverse prese a livelli diversi.

La risoluzione dei nomi è una terza questione separata. Scegliere quali richieste vanno a un proxy non dice nulla su quale resolver risponda loro, e trattare le due cose come un’unica impostazione produce perdite invisibili finché qualcuno non prova dall’esterno. Decidete dove viene risposta ogni query e scrivete quella decisione accanto alla regola del proxy. Un resolver che cambia perché il tunnel è salito sposterà la risposta in silenzio.

Testare entrambi i percorsi, non solo quello felice

Testate un nome host che dovrebbe corrispondere, un nome host che non dovrebbe, e l’apice del dominio, poiché l’apice è il caso più spesso mancato da una regola di solo suffisso. Poi confermate quale percorso ha preso davvero ogni richiesta invece di dedurlo dal fatto che la pagina sia stata caricata.

Infine, testate il ramo di errore. Un proxy irraggiungibile dovrebbe fallire in un modo che avete deciso in anticipo, invece di tornare silenziosamente a una connessione diretta. La guida alle opzioni di rete documenta con precisione i parametri di route; la metà dominio di questa progettazione vive interamente al di fuori di essa.

Articoli correlati