Perché la tua mappatura delle porte VPN di Docker non raggiunge mai OpenVPN

Il tuo container può ascoltare su UDP 1195 mentre l’host pubblica 1194, ed è corretto finché la mappatura lo dice. I numeri formano una tabella di traduzione: il client compone la porta dell’host, Docker riscrive la destinazione verso la porta del container e OpenVPN risponde sulla porta che la sua stessa configurazione nomina. Una discrepanza su uno di questi anelli produce un guasto silenzioso che sembra un firewall. I certificati e i cifrari stanno a valle e non possono ripararlo.

Segui un pacchetto dal client al processo prima di cambiare qualcosa sull’autenticazione.

Tre numeri, una connessione

I tre numeri sono la destinazione remota usata dal client, la mappatura pubblicata sull’host e l’ascoltatore dentro il container. Non devono essere uguali, ma devono concatenarsi. Numeri uguali sono un caso speciale che è per caso il più comune, perciò una discrepanza è facile da scrivere una volta e difficile da vedere dopo.

Scrivi la catena su una riga prima di fare debug: indirizzo e porta del client, mappatura dell’host, ascoltatore del container, trasporto. Un difetto nella catena si manifesta come un numero che compare due volte con valori diversi.

Cosa dice davvero la sintassi breve

Nella forma breve il lato sinistro è la porta dell’host e il lato destro la porta del container, e un suffisso con barra sceglie il trasporto. Se ometti il suffisso, Docker tratta la mappatura come TCP, quindi un ascoltatore UDP dietro una mappatura senza protocollo è un ascoltatore che nessuno può raggiungere. Quel valore predefinito è documentato e sorprende ancora chi ha fatto combaciare i numeri e ha considerato la questione chiusa.

La forma lunga fissa esplicitamente l’indirizzo di bind e il protocollo, cosa che vale le righe in più per tutto ciò che guarda verso una rete. Rileggi la mappatura pubblicata invece di fidarti del file che l’ha prodotta.

ports:
  - 1194:1195/udp

Dove il pacchetto può fermarsi

Una richiesta può essere scartata prima di Docker, in Docker o presso l’ascoltatore. Davanti a Docker può esserci un firewall cloud o un router che fa il proprio inoltro, e quel dispositivo ha bisogno della porta rivolta all’host e del trasporto giusto. Dentro Docker, una mappatura verso la porta di container sbagliata inoltra verso un socket chiuso.

Poi l’ascoltatore: la configurazione di OpenVPN nomina una porta e un protocollo, e un client che ne raggiunge un’altra dentro il container non arriva a nulla. Testare un servizio UDP con TCP non dimostra nulla in nessuna di queste fasi, quindi usa il trasporto che userà il client.

Gli indirizzi di bind decidono la raggiungibilità

Una mappatura pubblicata legata a loopback è raggiungibile solo dall’host, mentre una legata a tutte le interfacce è raggiungibile ovunque il firewall lo permetta. Le due sembrano identiche in un file Compose che omette l’indirizzo, e il valore predefinito di Docker è quello largo.

Decidi quale esposizione intende il deployment, poi scrivila in modo esplicito. Un test interno che si connette via loopback e un client remoto che non riesce a connettersi possono entrambi descrivere accuratamente lo stesso container.

Leggi lo stato in esecuzione

Ispeziona la mappatura effettiva del container in esecuzione e l’ascoltatore nel suo namespace di rete. Un file Compose può essere stato modificato dopo l’avvio del container, i metadati dell’immagine possono dichiarare una porta senza pubblicarla, e un secondo container può già tenere la porta dell’host. Dichiarare una porta in un’immagine non è pubblicarla, e nessuna delle due cose equivale ad ascoltare.

Tre stati diversi, tre comandi diversi, e solo l’ultimo coinvolge OpenVPN.

Quando la mappatura è corretta

Una volta che il pacchetto raggiunge OpenVPN, il suo log è il posto dove leggere di TLS e autenticazione. Rigenerare certificati per riparare un pacchetto che non è mai arrivato è lavoro sprecato che aggiunge una seconda variabile. Tieni la nota della mappatura accanto al profilo del client, così la persona successiva legge una riga invece di riscoprire tutti e tre i numeri. Una cattura di pacchetti lato host stabilisce quale dei tre anelli è sbagliato, e costa meno di una rigenerazione di certificato.

La pubblicazione tramite bridge è il caso descritto qui. La rete host e gli indirizzi dei container instradati saltano la traduzione, quindi gli stessi numeri significano un’altra cosa in quei progetti.