Docker-poortpublicatie en VPN-bronnen: twee overeenkomsten die u mist

De regel zegt het adres van de VPN-server toe te staan naar de gepubliceerde dienst, en toch valt de verbinding weg. Dat resultaat is gebruikelijk en het is geen Docker-fout. Twee afzonderlijke overeenkomsten zijn verkeerd: de bron die u schreef is misschien niet de bron die de host ontvangt, en de poort die u schreef is misschien niet de poort die het filter ziet. Beide herstellen vereist kijken naar het pakketpad in plaats van het servicediagram.

De mythe: sta de VPN-server toe en je bent klaar

Een gerouteerde VPN kan het tunneladres van de client helemaal tot de Docker-host bewaren. Een gateway die bronvertaling uitvoert, kan dat adres door zijn eigen adres vervangen. Beide ontwerpen zijn legitiem, en ze leveren verschillende bronnen voor dezelfde gebruikersactie.

Dus de uitdrukking IP van de VPN-server beschrijft een aanname, geen waarneming. Tot u weet welk van de twee ontwerpen voor u staat, is de regel een gok.

Bron: clientpool of vertaalde gateway

Controleer vier dingen in volgorde. Eerst de clientadrespool, bijvoorbeeld 10.90.0.0/24. Ten tweede of de gateway die pool vertaalt voordat hij de host bereikt. Ten derde de bron die de host werkelijk waarneemt voor één nieuwe verbinding. Ten vierde of applicatieauthenticatie individuele gebruikers onderscheidt, want een gedeeld vertaald adres kan dat niet.

Als de pool behouden blijft, mist een regel die alleen op het openbare adres van de gateway past elke client. Als de gateway opzettelijk vertaalt, laat toestaan van het vertaalde adres elke gebruiker erachter binnen, wat aanvaardbaar kan zijn voor een dienst met eigen aanmelding en onaanvaardbaar voor al het andere.

Poort: DNAT verandert het nummer dat u matcht

Bij gewone Linux-brugpublicatie met Docker iptables wordt een hosttoewijzing van 8443 naar containerpoort 443 vertaald voordat het doorstuurfilter draait. Het pakket komt bij het filter aan met bestemmingspoort 443. Een regel die op dat moment op 8443 past, gaat nooit af, ook al is 8443 wat de client typte.

De gepubliceerde poort bestaat nog steeds in verbindingsregistratie, daarom kan de oorspronkelijke bestemming daar worden gematcht wanneer u die echt nodig hebt.

Bepaal welk nummer de bedoeling uitdrukt. Match de containerpoort na DNAT wanneer de regel de dienst in de container beschermt. Match de oorspronkelijke bestemming met de conntrack-optie wanneer de regel moet beschrijven wat de client vroeg, en accepteer de extra matchkosten en de zorg voor de regelvolgorde die daarmee komen.

Keten: DOCKER-USER, niet INPUT

De iptables-gids van Docker plaatst het doorstuurbeleid voor gebruikers in de DOCKER-USER-keten, die wordt geëvalueerd vóór de eigen doorstuurregels van Docker. Een regel die van een hostdienst naar de INPUT-keten is gekopieerd, filtert verkeer dat aan de host is gericht, niet verkeer dat naar een container wordt doorgestuurd. Die fout levert een regel op die er goed uitziet en geen effect heeft op het containerpad.

Houd het bronbereik, de effectieve bestemmingspoort, het protocol en de inkomende interface samen in dezelfde regel. Een toestemming alleen op bron voor elke doorgestuurde bestemming is breder dan het toelaten van één gepubliceerde dienst.

Verifieer met verse verbindingen

Test beide richtingen met nieuwe verbindingen: één toegestane VPN-client en één bron die geweigerd moet blijven. Bestaande verbindingsstatus kan een sessie in leven houden nadat het beleid is gewijzigd, dus een oude verbinding bewijst niets over de nieuwe regel. Controleer daarna het antwoordpad, want de container moet nog steeds terugrouteren naar de bron die hij ziet.

De iptables-gids van Docker documenteert de ketenorde en het poortvertaalgedrag achter deze controles. Lees hem voordat u een recept kopieert, en bevestig welke backend de geïnstalleerde Docker gebruikt, want de nftables-backend integreert beleid anders.