Pubblicazione delle porte Docker e sorgenti VPN: due corrispondenze che perdi
L’IP di un server VPN non è sempre la sorgente che Docker vede, e la porta dopo il DNAT non è quella pubblicata. Confronta entrambi i fatti con il percorso reale.
La regola dice di consentire l’indirizzo del server VPN verso il servizio pubblicato, e la connessione cade lo stesso. Questo esito è comune e non è un difetto di Docker. Due corrispondenze separate sono sbagliate: la sorgente che hai scritto potrebbe non essere quella che l’host riceve, e la porta che hai scritto potrebbe non essere quella che il filtro vede. Correggere entrambe richiede di guardare il percorso del pacchetto invece dello schema del servizio.
Il mito: consenti il server VPN e hai finito
Una VPN instradata può conservare l’indirizzo del tunnel del client fino all’host Docker. Un gateway che esegue traduzione della sorgente può sostituire quell’indirizzo con il proprio. Entrambi i progetti sono legittimi e producono sorgenti diverse per la stessa azione dell’utente.
Quindi la frase IP del server VPN descrive un’ipotesi, non un’osservazione. Finché non sai quale dei due progetti hai davanti, la regola è una congettura.
Sorgente: pool di client o gateway tradotto
Controlla quattro cose in ordine. Prima, il pool di indirizzi dei client, per esempio 10.90.0.0/24. Seconda, se il gateway traduce quel pool prima che raggiunga l’host. Terza, la sorgente che l’host osserva davvero per una nuova connessione. Quarta, se l’autenticazione dell’applicazione distingue i singoli utenti, perché un indirizzo tradotto condiviso non può farlo.
Se il pool viene conservato, una regola che corrisponde solo all’indirizzo pubblico del gateway manca ogni client. Se il gateway traduce di proposito, consentire l’indirizzo tradotto ammette ogni utente dietro di esso, il che può essere accettabile per un servizio con un proprio accesso e inaccettabile per qualsiasi altra cosa.
Porta: il DNAT cambia il numero che abbini
Nella pubblicazione ordinaria a ponte Linux con iptables di Docker, una mappatura dell’host da 8443 alla porta 443 del container viene tradotta prima che il filtro di inoltro venga eseguito. Il pacchetto arriva al filtro con porta di destinazione 443. Una regola che corrisponde a 8443 in quel punto non scatta mai, anche se 8443 è ciò che il client ha digitato.
La porta pubblicata esiste ancora nel tracciamento delle connessioni, perciò la destinazione originale può essere confrontata lì quando serve davvero.
Decidi quale numero esprime l’intenzione. Abbina la porta del container dopo il DNAT quando la regola protegge il servizio dentro il container. Abbina la destinazione originale con l’opzione conntrack quando la regola deve descrivere ciò che il client ha richiesto, e accetta il costo di corrispondenza aggiuntivo e la cura per l’ordine delle regole che ne derivano.
Catena: DOCKER-USER, non INPUT
La guida di iptables di Docker colloca la politica di inoltro dell’utente nella catena DOCKER-USER, che viene valutata prima delle regole di inoltro di Docker stesso. Una regola copiata da un servizio dell’host nella catena INPUT filtra il traffico indirizzato all’host, non il traffico inoltrato a un container. Questo errore produce una regola che sembra corretta e non ha alcun effetto sul percorso del container.
Tieni l’intervallo di sorgente, la porta di destinazione effettiva, il protocollo e l’interfaccia di ingresso insieme nella stessa regola. Un’autorizzazione basata solo sulla sorgente per ogni destinazione inoltrata è più ampia del consentire un solo servizio pubblicato.
Verifica con connessioni nuove
Prova entrambe le direzioni con connessioni nuove: un client VPN consentito e una sorgente che deve restare negata. Lo stato di connessione esistente può mantenere viva una sessione dopo il cambio di politica, quindi una vecchia connessione non dimostra nulla sulla nuova regola. Poi controlla il percorso di risposta, perché il container deve comunque instradare verso la sorgente che vede.
La guida di iptables di Docker documenta l’ordine delle catene e il comportamento di traduzione delle porte dietro questi controlli. Leggila prima di copiare una ricetta e conferma quale backend usa il Docker installato, perché il backend nftables integra la politica in modo diverso.