DNAT i ein VPN-container: vidaresending, ikkje INPUT

Etter DNAT blir ein førespurnad til tunneladressa vidaresend trafikk. Avgrens vidaresendingsregelen, les Docker-kjeda og vel ein returveg med vilje.

Førespurnaden kjem inn adressert til tunnel-IP-en og forlet same containeren adressert til ein naboteneste. Mellom dei to augneblinkane skreiv DNAT om destinasjonen, og pakken slutta å vere input for VPN-containeren. No er han vidaresend trafikk, vurdert av ein annan regel. Den endringa forklarer kvifor ein brannmurregel som ser rett ut for tunneladressa, ikkje har nokon verknad på den omsette sambindinga.

Følg pakken etter omsetjinga

Ta ein klientpool på 10.90.0.0/24 og ei tunneladresse på 10.90.0.1. To containerar står på same bru: 192.0.2.2 køyrer VPN og 192.0.2.3 køyrer applikasjonen. Ein klient koplar til 10.90.0.1:8080, og DNAT-regelen i namnerommet til VPN-containeren skriv det om til den verkelege adressa og porten til applikasjonen. Deretter sender ei rute pakken over brua. Desse adressene er illustrative, ikkje ei oppskrift for utrulling.

Porten applikasjonen faktisk lyttar på, kan avvike frå kvar ein port som er publisert på verten. Les lyttaren inne i containeren i staden for å anta at begge tala stemmer.

Løyvet høyrer til vidaresendingsvegen

VPN-containeren treng IP-vidaresending og eit vidaresendingsvedtak avgrensa til klientpoolen, adressa til applikasjonen og den tiltenkte porten. Etablerte svar treng sitt eige løyve. Ein regel som svarar til den opphavlege tunneladressa, vil ikkje svare etter DNAT, fordi destinasjonen alt er endra. Eit INPUT-løyve er feil krok for trafikk som ikkje lenger er adressert til denne verten.

Hald omfanget smalt: eitt kjeldeområde, éin destinasjon, éin teneste. Ein ettergjevande vidaresendingsregel er lettare å skrive og mykje vanskelegare å forsvare seinare.

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 kjeder er ikkje kjedene til containeren din

Reglar inne i namnerommet til containeren er ikkje reglane til Docker-verten. Når trafikk kryssar frå tunellgrensesnittet til brua, kan bru-brannmuren til verten ta eit anna vedtak. Med iptables-backenden til Docker er dei dokumenterte vidaresendingskjedene og samsvara punkta etter DNAT der det vedtaket dukkar opp.

Dockers brannmurreferanse skildrar desse kjedene og samsvaret etter DNAT. Ikkje rett ei manglande godkjenning ved å slå av brannmurstyringa til Docker eller gjere kvar kjede ettergjevande, fordi det fjernar grensa du prøver å bruke.

Gjer returvegen til eit medvite val

Dersom kjeldeadressa blir halden, ser applikasjonen 10.90.0.x og må rute svar tilbake gjennom VPN-containeren. Elles sender den vanlege Docker-gatewayen dei til verten, som ikkje eig tunnelen. Alternativet er ei smalt avgrensa kjeldeomsetjing ved VPN-containeren, som forenklar svaret men gøymer klienten for applikasjonen. Vel med vilje og skriv ned kva du valde.

Test ei ny tillaten sambinding frå ein vanleg klient, og stadfest deretter at urelaterte portar blir verande lukka. Når ein pakke forsvinn, gransk VPN-namnerommet, namnerommet til applikasjonen og den eigne loggen til applikasjonen. Ein ping til bru-gatewayen er ikkje ein aksepttest for tenesta.

Hald reglane i den støtta oppstartskonfigurasjonen til containeren, fordi interaktive endringar forsvinn når han blir laga på nytt. Publisering av ein vertsport er ein annan eksponeringsveg og er ikkje nødvendig berre fordi tenesta er nåbar gjennom tunnelen.

Relaterte artiklar