Docker-portpublicering kontra VPN: vart svaret tar vägen

En publicerad container svarar från sin egen adress före omvänd NAT. Två designer kan hålla det svaret på den offentliga vägen, med olika kostnader.

Värden fortsätter att svara på SSH efter att en VPN med full tunnel kommit upp, medan en Docker-publicerad tjänst på samma maskin tystnar. Det är inget fel på lyssnaren: containern körs, portmappningen finns och paketet anländer. Containern är frisk och begäran når den faktiskt. Det som skiljer är var svaret börjar när Linux väljer sin väg, och den skillnaden avgör vilken av de två designerna nedan du behöver.

Följ tuple genom destinations-NAT

Ta en värd på 192.0.2.10 som publicerar TCP 2222 till en container på 172.30.240.5:22. En begäran från 198.51.100.25 översätts innan den når containern, och containern svarar som sig själv.

WAN request:      198.51.100.25 -> 192.0.2.10:2222
after DNAT:       198.51.100.25 -> 172.30.240.5:22
container reply:  172.30.240.5:22 -> 198.51.100.25

Vid värdens vägval bär svaret fortfarande containerns källadress. Den omvända översättningen återställer den publicerade tuple senare, och det är därför paketet ser fel ut just i det ögonblick vägen väljs.

Varför en regel bara för värden missar det

En regel som bara väljer WAN-tabellen för paket från 192.0.2.10 täcker värdens egna daemoner och missar helt detta vidarebefordrade svar. Källadressen i svaret är 172.30.240.5, inte värden.

Överkorrigeringen är att routa allt från containern via WAN, vilket också befriar containerns orelaterade utgående anslutningar från VPN. Det är en annan policy än den som efterfrågades, och det överraskar vanligtvis någon senare.

Post-DNAT-matchning är en annan hook

Dockers dokumentation om brandväggar noterar att vanlig användarfiltrering ser destinationen efter DNAT, så att matcha den publicerade porten 2222 i en normal regel är inte samma sak som att matcha containerporten 22. Om den ursprungliga tuple är viktig, använd den stödda ursprungliga-destination-mekanismen i stället för att gissa vilken port som är synlig.

Den här hook-förvirringen producerar regler som ser korrekta ut och aldrig matchar. Kontrollera räknarna på själva regeln innan du skriver om policyn. En regel utan träffar säger dig att den utvärderas någonstans dit paketet aldrig når.

Design A: bär beslutet som anslutningstillstånd

En anslutningsmarkering kan bära ingångsbeslutet genom översättningen, men den måste återställas på paketet före den vägslagning som betyder något. Stegen är:

  1. Reservera ett markeringsfält och en regelprioritet som inte krockar med Docker, VPN:en eller en annan policyägare.
  2. Identifiera bara den avsedda nya WAN-anslutningen vid en punkt före DNAT där anslutningsspårning är tillgänglig.
  3. Registrera beslutet på anslutningsmarkeringen, utan att tvinga själva den ursprungliga begäran in i WAN-tabellen.
  4. I svarsriktningen, återställ bara dina egna markeringsbitar på paketet före routning.
  5. Välj en komplett WAN-tabell tidigt nog så att en VPN-regel inte kan vinna först.

Den tabellen behöver de faktiska anslutna rutterna och gatewayen. Den behöver också ett definierat beteende när rutten saknas. Tyst fall in i tunneln är det sämsta utfallet, eftersom konfigurationen fortfarande ser ut att fungera. Misslyckas stängt i stället och logga det.

Design B: terminera på värden

En medvetet konfigurerad frontend på värdsidan, som en TCP-proxy eller en omvänd proxy framför containern, håller svaret med ursprung i värdens adress. Regler skrivna för värden beter sig då som förväntat, och containern stannar på sitt privata nät.

Priset är ännu en rörlig del med egen konfiguration, hantering av källadresser och åtkomstkontroller. Det är vanligtvis den enklare stödda gränsen, och det är ofta rätt svar när routningspolicyn skulle underhållas av en person som kan komma att sluta.

Verifiera ändringen, inte avsikten

Öppna en ny auktoriserad anslutning från den offentliga sidan och bekräfta att svaret lämnar det avsedda gränssnittet. Kontrollera sedan att en orelaterad begäran som containern startar fortfarande följer VPN:en.

Töm inte maskinens anslutningstabell för att testa en regel: befintliga poster behåller sin tidigare mappning, och tömningen förstör allt annat på värden. Att publicera en port definierar nåbarhet. Det definierar inte svarsvägen. Skriv ner den valda designen med dess tabellnamn, så att nästa person inte behöver upptäcka den igen under en incident.

Relaterade artiklar