VPN dietro un NAT che non potete configurare: cosa funziona ancora

Ogni estremità di tunnel ha bisogno di un indirizzo e di una porta che l'altro lato possa raggiungere, e un router che non amministrate è il motivo abituale per cui quel requisito fallisce. La parte interessante non è che esistano trucchi, ma che ciascuno dipenda da una proprietà di una tabella di mappatura che non vedete dal client. Due di queste proprietà decidono quasi tutto: come viene creata una mappatura e se accetta pacchetti da un indirizzo con cui l'interno non ha mai comunicato. Ordinate l'ambiente secondo queste proprietà e le soluzioni smettono di essere folclore.

La tabella di mappatura decide tutto

La traduzione degli indirizzi di rete tiene una tabella in cui un indirizzo e una porta interni sono registrati contro un indirizzo e una porta pubblici. Le risposte che corrispondono a un record vengono ritradotte, e un pacchetto che arriva da fuori senza un record corrispondente non ha alcuna destinazione. Questo singolo comportamento spiega perché un listener dietro il router è irraggiungibile da internet. Spiega anche perché il primo pacchetto in ciascuna direzione deve nascere all'interno.

Guardate la tabella dal lato del router e le soluzioni diventano ovvie: o qualcosa crea una voce permanente, o ne crea una temporanea e la mantiene fresca, oppure il traffico non prende mai quella strada. Il resto dell'articolo sono questi tre casi in ordine. Niente qui dipende da una funzione del fornitore oltre a ciò che la tabella registra.

Cosa può e cosa non può fare il servizio di rendezvous

L'hole punching UDP usa il record in uscita come un'apertura temporanea invece di sconfiggere il filtro. Entrambi i peer contattano un servizio di rendezvous, che apprende ogni estremità pubblica e riporta all'altro lato la sua estremità. Poi entrambi inviano l'uno verso l'altro, e ogni pacchetto in uscita crea o aggiorna il record che lascia entrare la risposta. L'ordine è ciò che lo fa funzionare, e l'ordine è anche ciò che lo rende fragile: un peer che invia prima che l'altro lato abbia creato il proprio record viene semplicemente scartato, mentre un nuovo tentativo un attimo dopo riesce. Il servizio stesso non trasporta traffico VPN, quindi la sua unica leva è il tempismo che coordina.

Il comportamento della mappatura decide il resto, e RFC 4787 nomina le tre forme: indipendente dall'estremità, dipendente dall'indirizzo e dipendente da indirizzo e porta. Con l'ultima, la porta che un peer deve puntare cambia a ogni destinazione, così la previsione smette di essere affidabile. È qui che la tecnica incontra i suoi vicoli ciechi, perché il NAT di livello operatore e un firewall aziendale rigido eliminano entrambi la prevedibilità di cui lo schema ha bisogno, e nessuna quantità di tentativi la riporta.

Keepalive, riavvii e l'estremità che si sposta

Un percorso perforato è un flusso e non un listener, quindi tutto ciò che ci gira sopra deve sopravvivere al cambiamento. Deve mantenere viva la mappatura con traffico periodico, accorgersi quando l'estremità pubblica si sposta e ristabilirsi dopo il riavvio del router o la riassegnazione dell'indirizzo. I prodotti mesh VPN mettono quella logica nel proprio piano di controllo, mentre un server semplice la lascia a voi. I keepalive aiutano solo finché sopravvive la stessa mappatura, e consumano batteria su un client mobile, per questo un intervallo aggressivo non è gratis.

Un portatile che dorme un'ora di solito torna su un'estremità pubblica diversa. Tutto ciò che ristabilisce il percorso deve essere eseguito di nuovo dall'interno, il che rimette lo stesso requisito sul client.

Tre modi per aggirare un inoltro mancante

Il primo modo chiede al router di creare lui stesso la voce, tramite UPnP IGD, NAT-PMP o PCP, quando la funzione esiste ed è attiva. Il secondo consegna il traffico a un relay con indirizzo pubblico, che funziona sempre e costa sempre larghezza di banda più un confine di fiducia diverso. Il terzo inverte la direzione: l'host interno apre un tunnel in uscita verso un server pubblico e tutto il resto viaggia al suo interno.

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

Un'estremità di relay rende visibile questo scambio nella configurazione del client, dove l'estremità è un relay e non l'indirizzo proprio di un peer. Il keepalive persistente mantiene calda la mappatura, e i prefissi consentiti decidono cosa il client può inviare attraverso. Un tunnel inverso dall'host interno è la stessa idea con un altro proprietario, e non richiede alcuna modifica al NAT. Ciascuno dei tre rimuove il requisito in ingresso senza sconfiggere un firewall che blocca per progettazione il traffico non richiesto, perché il traffico comincia comunque all'interno.

Adattate la soluzione a chi possiede il router

Se amministrate il router, un inoltro UDP statico è più semplice da verificare di qualsiasi schema di perforazione e fallisce in modi che vedete. Se no, scoprite se il fornitore offre un relay o un piano di controllo ospitato, e se la policy ne consentirebbe l'uso. Se nessuno dei due è disponibile, le scelte rimaste sono un tunnel inverso o accettare che l'estremità non sia raggiungibile dall'esterno. Annotare quale avete usato conta più di quanto sembri, perché le opzioni differiscono per chi può osservare il traffico e per cosa succede quando una terza parte cambia qualcosa.

Notate se il percorso con cui siete finiti era diretto o passava da un relay, perché questo solo fatto predice sia la latenza sia il comportamento in caso di guasto. RFC 4787 resta il riferimento per il comportamento di mappatura sotto tutto questo, e leggere la sua sezione sulla mappatura è più rapido che provare tre soluzioni in sequenza. Alla tabella non importa quale opzione avete scelto; registra solo cosa può fare il pacchetto successivo.