DNAT într-un container VPN: redirecționare, nu INPUT

Cererea sosește adresată către IP-ul tunelului și părăsește același container adresată către un serviciu vecin. Între aceste două momente DNAT a rescris destinația, iar pachetul a încetat să fie intrare pentru containerul VPN. Acum este trafic redirecționat, judecat de o altă regulă. Această schimbare explică de ce o regulă de firewall care pare corectă pentru adresa tunelului nu are niciun efect asupra conexiunii traduse.

Urmați pachetul după traducere

Luați un pool de clienți 10.90.0.0/24 și o adresă de tunel 10.90.0.1. Două containere stau pe un singur bridge: 192.0.2.2 rulează VPN-ul, iar 192.0.2.3 rulează aplicația. Un client se conectează la 10.90.0.1:8080, iar regula DNAT din spațiul de nume al containerului VPN o rescrie către adresa și portul reale ale aplicației. Apoi o rută trimite pachetul peste bridge. Aceste adrese sunt ilustrative, nu o rețetă de implementare.

Portul pe care aplicația chiar ascultă poate diferi de orice port publicat pe gazdă. Citiți ascultătorul din interiorul containerului în loc să presupuneți că ambele numere coincid.

Permisiunea aparține căii de redirecționare

Containerul VPN are nevoie de redirecționare IP și de o decizie de redirecționare limitată la pool-ul de clienți, adresa aplicației și portul dorit. Răspunsurile stabilite au nevoie de propria permisiune. O regulă care corespunde adresei originale a tunelului nu va corespunde după DNAT, deoarece destinația s-a schimbat deja. O permisiune INPUT este cârligul greșit pentru traficul care nu mai este adresat acestei gazde.

Păstrați domeniul îngust: un interval de surse, o destinație, un serviciu. O regulă de redirecționare permisivă este mai ușor de scris și mult mai greu de apărat mai târziu.

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

Lanțurile Docker nu sunt lanțurile containerului tău

Regulile din spațiul de nume al containerului nu sunt regulile gazdei Docker. Când traficul trece de la interfața tunelului la bridge, firewall-ul bridge-ului de pe gazdă poate lua o altă decizie. Cu backend-ul iptables al Docker, lanțurile de redirecționare documentate și punctele de potrivire după DNAT sunt locul unde apare acea decizie.

Referința firewall a Docker descrie acele lanțuri și potrivirea după DNAT. Nu reparați o acceptare lipsă dezactivând administrarea firewall-ului Docker sau făcând fiecare lanț permisiv, deoarece asta elimină granița pe care încercați să o folosiți.

Faceți din calea de întoarcere o alegere deliberată

Dacă adresa sursă este păstrată, aplicația vede 10.90.0.x și trebuie să dirijeze răspunsurile înapoi prin containerul VPN. Altfel, gateway-ul Docker obișnuit le va trimite la gazdă, care nu deține tunelul. Alternativa este o traducere de sursă strict limitată în containerul VPN, care simplifică răspunsul dar ascunde clientul de aplicație. Alegeți deliberat și notați pe care ați ales-o.

Testați o conexiune nouă permisă de la un client obișnuit, apoi confirmați că porturile nelegate rămân închise. Când un pachet dispare, inspectați spațiul de nume VPN, spațiul de nume al aplicației și logul aplicației. Un ping către gateway-ul bridge-ului nu este un test de acceptare pentru serviciu.

Păstrați regulile în configurația de pornire acceptată a containerului, deoarece modificările interactive dispar atunci când acesta este recreat. Publicarea unui port pe gazdă este o altă cale de expunere și nu este necesară doar pentru că serviciul este accesibil prin tunel.