Chi risponde davvero sull'indirizzo dedicato della VPN?

Un indirizzo che resta inutilizzato nell'allocazione dell'organizzazione non è un ascoltatore, e aggiungerlo a un firewall non ne crea uno. Qualcosa deve terminare IKE su quell'indirizzo, e il meccanismo cambia a seconda che sia il gateway a possedere l'indirizzo o sia un dispositivo a monte a tradurlo. È il percorso del pacchetto a distinguere i due casi, ed è ciò che decide quale funzione della piattaforma vi serve prima che qualcuno apra una richiesta di modifica. Modellate prima il percorso, poi scegliete.

Il percorso del pacchetto dietro l'indirizzo

Un peer invia IKE all'indirizzo che ha ricevuto, su UDP 500 o su UDP 4500 quando entra in gioco la traversata NAT. Il dispositivo che detiene quell'indirizzo sul percorso o riceve il datagramma in locale e vi risponde, oppure lo inoltra altrove. Sono le uniche due possibilità, e tutto il resto di questo articolo dipende da quale sia vera.

Ricevere in locale significa che su quel dispositivo esiste un socket, associato a quell'indirizzo. Inoltrare significa che il datagramma viene riscritto e inviato verso un altro punto terminale, che a quel punto detiene il socket. Una regola del firewall che consente UDP 500 non vi dice nulla su quale delle due cose stia accadendo.

Scrivete il registro prima di toccare qualcosa: l'indirizzo con cui i peer entrano in contatto, come lo consegna la rete a monte, l'interfaccia locale o il punto terminale logico che lo riceve, e il processo che risponde a IKE. Quattro righe, e ognuna può essere verificata. Quando una di esse è sconosciuta, quell'incognita è lavoro di progetto e non un dettaglio realizzativo da stabilire dopo. Compilarle dopo l'approvazione della richiesta di modifica è il modo in cui una regola di traduzione finisce sul dispositivo sbagliato.

Modello A: il gateway possiede l'indirizzo

Nel primo modello il gateway detiene lui stesso l'indirizzo, come indirizzo secondario su un'interfaccia esistente, come indirizzo su un'interfaccia dedicata, oppure come loopback che la piattaforma supporta come punto terminale del tunnel. Sono tre funzioni diverse con tre percorsi di configurazione diversi, e una piattaforma che ne supporta una può non supportare le altre.

Confermate che la piattaforma e la versione supportino esattamente questa disposizione prima di progettare su di essa. Un blocco instradato, un indirizzo aggiuntivo su un'interfaccia e un punto terminale loopback non sono intercambiabili, e la documentazione di una versione non promette che la successiva si comporti allo stesso modo.

ip -br addr show
ss -lunp | grep -E ':500|:4500'
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'

Il socket in ascolto è la prova. Se nulla è associato all'indirizzo, il gateway non è il terminatore qualunque cosa dica la tabella di routing, e una cattura di pacchetti mostrerà i datagrammi arrivare senza che nulla risponda.

Non collocate una seconda interfaccia in una sottorete che esiste già altrove nella topologia e non date per scontato che la piattaforma risolva la cosa. Sottoreti di interfaccia sovrapposte producono una selezione della sorgente ambigua e, su molte piattaforme, un rifiuto totale della configurazione.

Modello B: un dispositivo a monte la traduce

Nel secondo modello un firewall a monte detiene l'indirizzo dedicato e inoltra il traffico a un altro gateway VPN. È una traduzione di destinazione con percorso di ritorno, ed è un progetto del tutto valido finché è documentato come tale.

Ciò che non è, è la prova che il dispositivo a monte abbia acquisito un socket VPN locale. La traduzione inoltra pacchetti; non rende il dispositivo superiore un risponditore IKE. Se la regola a monte viene rimossa o il suo percorso di ritorno si rompe, la VPN si ferma anche se il gateway è sano e i suoi ascoltatori sono intatti.

Registrate entrambi gli indirizzi: quello con cui i peer entrano in contatto e quello che il gateway vede davvero. Poi registrate il trasporto e il percorso di ritorno, perché una traduzione che funziona per UDP 500 ma non per ESP incapsulato si connetterà e poi non riuscirà a trasportare traffico, il che è un guasto confuso da diagnosticare più avanti.

L'identità non è l'indirizzo esterno

IPsec separa il punto terminale del tunnel dal traffico che protegge, e l'architettura tiene queste decisioni in luoghi diversi. Cambiare l'indirizzo con cui i peer entrano in contatto non cambia automaticamente quali prefissi interni sono ammessi, quali rotte vengono installate o quali risorse la sessione può raggiungere.

L'identità autenticata è di nuovo separata. IKEv2 trasporta un carico utile di identità e uno scambio di autenticazione che non devono coincidere con l'indirizzo esterno del pacchetto, ed è proprio per questo che un progetto tradotto può ancora autenticarsi correttamente.

Quell'indipendenza è utile e anche una trappola. Due nomi DNS che risolvono verso un ascoltatore ordinario non selezionano backend VPN diversi, e un certificato che nomina un'identità non soddisferà un peer che ne attende un'altra. Confermate cosa valida il peer prima di supporre che sia solo l'indirizzo a deciderlo.

Accettate il progetto osservando una connessione

Controllate dove viene effettivamente consegnata una nuova connessione autorizzata, quale identità risponde e quale flusso privato viene poi consentito. Tre osservazioni, tre livelli diversi, e una risoluzione pubblica riuscita dell'indirizzo non ne verifica nessuna.

Conservate anche il caso negativo: un peer che non dovrebbe essere accettato, o un prefisso interno che non dovrebbe essere raggiungibile, verificato dopo la modifica. Il registro che avete scritto all'inizio è ciò che rende possibile quel test senza ricostruire il progetto a memoria.

Il senso di tutto questo è permettere al proprietario della rete di scegliere un metodo di allocazione supportato invece di affidarsi a un'affermazione generale su ciò che ogni firewall può fare con un indirizzo in più. È esattamente lì che questi progetti sbagliano, perché suona plausibile su ogni piattaforma e in generale non è vera su nessuna. Il registro di quattro righe lo risolve per la vostra piattaforma in dieci minuti.