DNAT i en VPN-container: videresendelse, ikke INPUT

Anmodningen ankommer med tunnel-IP som adresse og forlader den samme container med en nabotjenestes adresse. Mellem de to øjeblikke har DNAT omskrevet destinationen, og pakken holdt op med at være input for VPN-containeren. Nu er den videresendt trafik, som vurderes af en anden regel. Det skift forklarer, hvorfor en firewallregel, der ser rigtig ud for tunneladressen, ingen effekt har på den oversatte forbindelse.

Følg pakken efter oversættelsen

Tag en klientpulje på 10.90.0.0/24 og en tunneladresse på 10.90.0.1. To containere står på samme bridge: 192.0.2.2 kører VPN, og 192.0.2.3 kører applikationen. En klient forbinder til 10.90.0.1:8080, og DNAT-reglen i VPN-containerens namespace omskriver det til applikationens rigtige adresse og port. En rute sender derefter pakken over bridge. De adresser er illustrative, ikke en opskrift til udrulning.

Den port, applikationen faktisk lytter på, kan afvige fra enhver port, der er udgivet på værten. Læs lytteren inde i containeren i stedet for at antage, at begge tal stemmer overens.

Tilladelsen hører til videresendelsesvejen

VPN-containeren skal have IP-videresendelse og en videresendelsesbeslutning afgrænset til klientpuljen, applikationens adresse og den tilsigtede port. Etablerede svar skal have deres egen tilladelse. En regel, der matcher den oprindelige tunneladresse, matcher ikke efter DNAT, fordi destinationen allerede er ændret. En INPUT-tilladelse er den forkerte krog til trafik, der ikke længere er adresseret til denne vært.

Hold omfanget snævert: ét kildeområde, én destination, én tjeneste. En eftergivende videresendelsesregel er lettere at skrive og meget sværere at forsvare senere.

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

Dockers kæder er ikke din containers kæder

Regler inde i containerens namespace er ikke Docker-værtens regler. Når trafik krydser fra tunnelinterfacet til bridge, kan værtens bridge-firewall træffe en anden beslutning. Med Dockers iptables-backend er de dokumenterede videresendelseskæder og matchpunkterne efter DNAT der, hvor den beslutning viser sig.

Dockers firewallreference beskriver disse kæder og matchet efter DNAT. Ret ikke en manglende accept ved at slå Dockers firewallstyring fra eller gøre hver kæde eftergivende, fordi det fjerner den grænse, du prøver at bruge.

Gør returvejen til et bevidst valg

Hvis kildeadressen bevares, ser applikationen 10.90.0.x og skal rute svar tilbage gennem VPN-containeren. Ellers vil dens almindelige Docker-gateway sende dem til værten, som ikke ejer tunnelen. Alternativet er snæver kildeoversættelse ved VPN-containeren, som forenkler svaret men skjuler klienten for applikationen. Vælg med vilje, og skriv ned hvilken du valgte.

Test en ny tilladt forbindelse fra en almindelig klient, og bekræft derefter, at urelaterede porte forbliver lukkede. Når en pakke forsvinder, undersøg VPN-namespace, applikationens namespace og applikationens egen log. En ping til bridge-gatewayen er ikke en accepttest for tjenesten.

Hold reglerne i containerens understøttede opstartskonfiguration, fordi interaktive ændringer forsvinder, når den genskabes. Udgivelse af en værtport er en anden eksponeringsvej og er ikke nødvendig, bare fordi tjenesten er nåelig gennem tunnelen.