DNAT in un container VPN: inoltro, non INPUT

La richiesta arriva indirizzata all'IP del tunnel ed esce dallo stesso container indirizzata a un servizio vicino. Tra questi due momenti DNAT ha riscritto la destinazione e il pacchetto ha smesso di essere input per il container VPN. Ora è traffico inoltrato, giudicato da un'altra regola. Questo passaggio spiega perché una regola del firewall che sembra corretta per l'indirizzo del tunnel non ha alcun effetto sulla connessione tradotta.

Segui il pacchetto dopo la traduzione

Prendi un pool di client 10.90.0.0/24 e un indirizzo di tunnel 10.90.0.1. Due container stanno su un unico bridge: 192.0.2.2 esegue la VPN e 192.0.2.3 esegue l'applicazione. Un client si connette a 10.90.0.1:8080, e la regola DNAT nello spazio dei nomi del container VPN la riscrive all'indirizzo e alla porta reali dell'applicazione. Poi una rotta invia il pacchetto attraverso il bridge. Questi indirizzi sono illustrativi, non una ricetta di distribuzione.

La porta su cui l'applicazione ascolta davvero può differire da qualsiasi porta pubblicata sull'host. Leggi l'ascoltatore dentro il container invece di presumere che i due numeri coincidano.

Il permesso appartiene al percorso di inoltro

Il container VPN ha bisogno dell'inoltro IP e di una decisione di inoltro limitata al pool di client, all'indirizzo dell'applicazione e alla porta prevista. Le risposte stabilite hanno bisogno del proprio permesso. Una regola che corrisponde all'indirizzo originale del tunnel non corrisponderà dopo DNAT, perché la destinazione è già cambiata. Un permesso INPUT è l'aggancio sbagliato per traffico che non è più indirizzato a questo host.

Mantieni lo scopo stretto: un intervallo di origine, una destinazione, un servizio. Una regola di inoltro permissiva è più facile da scrivere e molto più difficile da difendere in seguito.

docker exec vpn-container ip route get 192.0.2.3
docker exec vpn-container iptables -t nat -S
docker exec vpn-container iptables -S FORWARD

Le catene di Docker non sono le catene del tuo container

Le regole dentro lo spazio dei nomi del container non sono le regole dell'host Docker. Quando il traffico passa dall'interfaccia del tunnel al bridge, il firewall del bridge sull'host può prendere un'altra decisione. Con il backend iptables di Docker, le catene di inoltro documentate e i punti di corrispondenza dopo DNAT sono dove quella decisione compare.

Il riferimento firewall di Docker descrive quelle catene e la corrispondenza dopo DNAT. Non correggere un'accettazione mancante disattivando la gestione del firewall di Docker o rendendo permissiva ogni catena, perché così rimuovi il confine che stai cercando di usare.

Rendi il percorso di ritorno una scelta deliberata

Se l'indirizzo di origine viene conservato, l'applicazione vede 10.90.0.x e deve instradare le risposte indietro attraverso il container VPN. Altrimenti il suo normale gateway Docker le invierà all'host, che non possiede il tunnel. L'alternativa è una traduzione di origine strettamente limitata nel container VPN, che semplifica la risposta ma nasconde il client all'applicazione. Scegli di proposito e annota quale hai scelto.

Prova una nuova connessione consentita da un client ordinario, poi conferma che le porte non correlate restano chiuse. Quando un pacchetto scompare, ispeziona lo spazio dei nomi della VPN, quello dell'applicazione e il log dell'applicazione stessa. Un ping al gateway del bridge non è un test di accettazione del servizio.

Mantieni le regole nella configurazione di avvio supportata del container, perché le modifiche interattive svaniscono quando viene ricreato. La pubblicazione di una porta sull'host è un'altra via di esposizione e non serve solo perché il servizio è raggiungibile attraverso il tunnel.