Le porte UDP fisse possono saltare l'inoltro delle porte, ma non tutti i NAT
Un firewall con stato ammette il pacchetto del peer come traffico di ritorno quando entrambe le estremità fissano una porta. Ecco quando funziona, e cosa vi mette fine in silenzio.
Due router domestici, nessuna porta inoltrata e una VPN che a volte si connette lo stesso. UDP lo consente, perché un firewall ammetterà un pacchetto che riesce ad abbinare a un flusso che la macchina ha già avviato. È un trucco condizionale, non una funzionalità, e le condizioni sono facili da enunciare una volta che sai cosa confronta il firewall. Sono anche il motivo per cui profili identici si comportano diversamente su reti diverse.
Il confronto che fa un firewall
Ogni datagramma in uscita crea una voce di breve durata: indirizzo di origine, porta di origine, indirizzo di destinazione, porta di destinazione. Tutto ciò che arriva e corrisponde alla voce viene trattato come risposta e lasciato passare. Le regole in ingresso non c'entrano.
La domanda quindi non è se il firewall fa entrare il peer. È se il pacchetto del peer somiglia alla risposta che la voce attende. Cambia un campo di quella tupla a quattro parti e il pacchetto diventa un estraneo. Per questo una configurazione funzionante può rompersi quando cambia solo il numero di porta, e per questo la stessa porta può funzionare su un router e fallire sul successivo.
Fissa la porta di origine locale e lo stesso numero compare su entrambi i lati dello scambio. È tutto il meccanismo, e spiega perché il trucco è fragile anziché misterioso.
Fissare una porta a ciascuna estremità
La porta UDP predefinita di OpenVPN è 1194, e lport imposta la porta di origine da cui invia. Fissa entrambi i peer e la tupla in uscita di ciascuno punta a una porta su cui l'altro è in ascolto:
# peer A
lport 1194
remote 198.51.100.20 1194
# peer B
lport 1194
remote 203.0.113.10 1194
Funziona solo finché nessun router tra loro riscrive la porta di origine. Quando i pacchetti compaiono in una cattura ma non sale alcun tunnel, la riscrittura è il primo sospetto.
Dove la tupla smette di corrispondere
Un NAT che mappa per destinazione assegna a ciascun peer una porta esterna diversa. L'indirizzo che è stato detto al tuo peer di usare non è quello che lo raggiunge, quindi il pacchetto in ingresso non corrisponde a nulla e viene scartato in silenzio.
La traduzione a livello di operatore, il NAT impilato e la randomizzazione delle porte finiscono tutte allo stesso modo. Così pure qualsiasi scatola intermedia che riscrive le porte lasciando in pace gli indirizzi.
I trasporti a flusso stanno peggio. Un handshake TCP viene seguito passo per passo, quindi una VPN basata su TCP non può essere perforata affatto in questo modo e ha bisogno di un ascoltatore da qualche parte sul percorso.
Di solito una parte fallisce per prima
In pratica le due reti si comportano raramente allo stesso modo. Un router può assegnare una mappatura prevedibile mentre l'altro assegna porte per destinazione, e il risultato è una configurazione che funziona tra due case e fallisce da una rete mobile. I resoconti che si contraddicono di solito descrivono due coppie di router diverse. Nessuno dei due autori sbaglia, e nessuno dei due risultati si generalizza.
Scopri quale lato ha scartato il pacchetto prima di toccare i profili. Le catture su entrambe le estremità lo risolvono in un solo tentativo: i datagrammi che lasciano A e non raggiungono mai B significano che il flusso è stato riscritto in transito, mentre quelli che arrivano a B senza che torni alcuna risposta significano che il firewall non li ha accettati come correlati.
Due peer con indirizzi IPv6 pubblici aggirano tutto il problema. Senza traduzione non c'è nulla da abbinare, quindi basta una regola del firewall che nomini i peer e il progetto smette di dipendere dal comportamento del router.
Quando smettere di provare
Un host con indirizzo pubblico è la risposta affidabile. Può terminare il tunnel per entrambi i peer, o semplicemente aiutarli a scoprire l'attuale indirizzo esterno dell'altro, ed entrambe le soluzioni funzionano qualunque cosa facciano i NAT. Un overlay gestito offre lo stesso coordinamento se la politica lo consente.
Nessuna di queste soluzioni richiede un firewall disattivato. Spegnere la protezione per vincere la connessione diretta scarta il motivo per cui il tentativo diretto era attraente, e lascia la macchina aperta per tutta la durata del test.
Prova prima la soluzione diretta, poi annota quello che hai visto. Il comportamento del NAT e la cattura che l'ha mostrato valgono più della coppia di porte che hai finito per usare, perché la prossima rete sarà diversa. Il manuale di OpenVPN 2.6 documenta lport e le opzioni remote da cui dipende.