DNAT i en VPN-container: videresending, ikke INPUT

Etter DNAT blir en forespørsel til tunneladressen videresendt trafikk. Avgrens videresendingsregelen, les Docker-kjeden og velg en returvei med vilje.

Forespørselen kommer inn adressert til tunnel-IP-en og forlater samme container adressert til en nabotjeneste. Mellom de to øyeblikkene skrev DNAT om destinasjonen, og pakken sluttet å være input for VPN-containeren. Nå er den videresendt trafikk, vurdert av en annen regel. Det skiftet forklarer hvorfor en brannmurregel som ser riktig ut for tunneladressen, ikke har noen effekt på den oversatte forbindelsen.

Følg pakken etter oversettelsen

Ta en klientpool på 10.90.0.0/24 og en tunneladresse på 10.90.0.1. To containere står på samme bro: 192.0.2.2 kjører VPN og 192.0.2.3 kjører applikasjonen. En klient kobler til 10.90.0.1:8080, og DNAT-regelen i navnerommet til VPN-containeren skriver det om til applikasjonens virkelige adresse og port. Deretter sender en rute pakken over broen. Disse adressene er illustrative, ikke en oppskrift for utrulling.

Porten applikasjonen faktisk lytter på, kan avvike fra enhver port som er publisert på verten. Les lytteren inne i containeren i stedet for å anta at begge tallene stemmer.

Tillatelsen hører til videresendingsveien

VPN-containeren trenger IP-videresending og en videresendingsbeslutning avgrenset til klientpoolen, applikasjonens adresse og den tiltenkte porten. Etablerte svar trenger sin egen tillatelse. En regel som samsvarer med den opprinnelige tunneladressen, vil ikke samsvare etter DNAT, fordi destinasjonen allerede er endret. En INPUT-tillatelse er feil krok for trafikk som ikke lenger er adressert til denne verten.

Hold omfanget smalt: ett kildeområde, én destinasjon, én tjeneste. En ettergivende videresendingsregel er lettere å skrive og mye vanskeligere å 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 kjeder er ikke din containers kjeder

Regler inne i containerens navnerom er ikke Docker-vertens regler. Når trafikk krysser fra tunellgrensesnittet til broen, kan vertens bro-brannmur ta en annen beslutning. Med Dockers iptables-backend er de dokumenterte videresendingskjedene og samsvarspunktene etter DNAT der den beslutningen dukker opp.

Dockers brannmurreferanse beskriver disse kjedene og samsvaret etter DNAT. Ikke rett en manglende godkjenning ved å slå av Dockers brannmurstyring eller gjøre hver kjede ettergivende, fordi det fjerner grensen du prøver å bruke.

Gjør returveien til et bevisst valg

Hvis kildeadressen bevares, ser applikasjonen 10.90.0.x og må rute svar tilbake gjennom VPN-containeren. Ellers sender den vanlige Docker-gatewayen dem til verten, som ikke eier tunnelen. Alternativet er en smalt avgrenset kildeoversettelse ved VPN-containeren, som forenkler svaret men skjuler klienten for applikasjonen. Velg med vilje og skriv ned hvilken du valgte.

Test en ny tillatt forbindelse fra en vanlig klient, og bekreft deretter at urelaterte porter forblir lukket. Når en pakke forsvinner, undersøk VPN-navnerommet, applikasjonens navnerom og applikasjonens egen logg. En ping til bro-gatewayen er ikke en aksepttest for tjenesten.

Hold reglene i containerens støttede oppstartskonfigurasjon, fordi interaktive endringer forsvinner når den gjenskapes. Publisering av en vertsport er en annen eksponeringsvei og er ikke nødvendig bare fordi tjenesten er nåbar gjennom tunnelen.

Relaterte artikler