DNAT në një kontejner VPN: përcjellje, jo INPUT

Kërkesa mbërrin e adresuar drejt IP-së së tunelit dhe largohet nga i njëjti kontejner e adresuar drejt një shërbimi fqinj. Midis këtyre dy momenteve DNAT rishkruan destinacionin, dhe paketa pushoi së qeni hyrje për kontejnerin VPN. Tani është trafik i përcjellë, i gjykuar nga një rregull tjetër. Ky ndryshim shpjegon pse një rregull i murit të zjarrit që duket i saktë për adresën e tunelit nuk ka asnjë efekt në lidhjen e përkthyer.

Ndiqni paketën pas përkthimit

Merrni një grup klientësh 10.90.0.0/24 dhe një adresë tuneli 10.90.0.1. Dy kontejnerë qëndrojnë në një urë: 192.0.2.2 ekzekuton VPN-në dhe 192.0.2.3 ekzekuton aplikacionin. Një klient lidhet me 10.90.0.1:8080, dhe rregulli DNAT në hapësirën e emrave të kontejnerit VPN e rishkruan atë në adresën dhe portën reale të aplikacionit. Pastaj një rrugë e dërgon paketën përmes urës. Këto adresa janë ilustruese, jo një recetë vendosjeje.

Porta ku aplikacioni dëgjon vërtet mund të ndryshojë nga çdo portë e publikuar në host. Lexoni dëgjuesin brenda kontejnerit në vend që të supozoni se të dy numrat përputhen.

Leja i përket rrugës së përcjelljes

Kontejneri VPN ka nevojë për përcjellje IP dhe për një vendim përcjelljeje të kufizuar në grupin e klientëve, adresën e aplikacionit dhe portën e synuar. Përgjigjet e vendosura kanë nevojë për lejen e tyre. Një rregull që përputhet me adresën origjinale të tunelit nuk do të përputhet pas DNAT, sepse destinacioni tashmë ka ndryshuar. Një leje INPUT është grep i gabuar për trafikun që nuk drejtohet më drejt këtij hosti.

Mbajeni shtrirjen të ngushtë: një interval burimi, një destinacion, një shërbim. Një rregull përcjelljeje lejues është më i lehtë për t'u shkruar dhe shumë më i vështirë për t'u mbrojtur më vonë.

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

Zinxhirët e Docker nuk janë zinxhirët e kontejnerit tuaj

Rregullat brenda hapësirës së emrave të kontejnerit nuk janë rregullat e hostit Docker. Kur trafiku kalon nga ndërfaqja e tunelit në urë, muri i zjarrit i urës në host mund të marrë një vendim tjetër. Me backend-in iptables të Docker, zinxhirët e dokumentuar të përcjelljes dhe pikat e përputhjes pas DNAT janë vendi ku shfaqet ky vendim.

Referenca e murit të zjarrit të Docker përshkruan ata zinxhirë dhe përputhjen pas DNAT. Mos e rregulloni një pranim që mungon duke çaktivizuar menaxhimin e murit të zjarrit të Docker ose duke bërë çdo zinxhir lejues, sepse kjo heq kufirin që po përpiqeni të përdorni.

Bëjeni rrugën e kthimit një zgjedhje të qëllimshme

Nëse adresa e burimit ruhet, aplikacioni sheh 10.90.0.x dhe duhet t'i drejtojë përgjigjet përsëri përmes kontejnerit VPN. Përndryshe porta e zakonshme Docker e tij do t'i dërgojë ato te hosti, i cili nuk e zotëron tunelin. Alternativa është një përkthim burimi i kufizuar ngushtë në kontejnerin VPN, që thjeshton përgjigjen por e fsheh klientin nga aplikacioni. Zgjidhni me qëllim dhe shkruani cilën zgjidhët.

Provoni një lidhje të re të lejuar nga një klient i zakonshëm, pastaj konfirmoni që portat e palidhura mbeten të mbyllura. Kur një paketë zhduket, inspektoni hapësirën e emrave të VPN-së, atë të aplikacionit dhe regjistrin e vetë aplikacionit. Një ping drejt portës së urës nuk është test pranimi për shërbimin.

Mbajini rregullat në konfigurimin e nisjes të mbështetur të kontejnerit, sepse redaktimet interaktive zhduken kur ai rikrijohet. Publikimi i një porte hosti është një rrugë tjetër ekspozimi dhe nuk është e nevojshme vetëm sepse shërbimi është i arritshëm përmes tunelit.