Docker-Portveröffentlichung und VPN-Quellen: zwei Treffer, die Sie verfehlen
Die IP eines VPN-Servers ist nicht immer die Quelle, die Docker sieht, und der Port nach DNAT ist nicht der veröffentlichte. Gleichen Sie beide Fakten mit dem realen Pfad ab.
Die Regel besagt, dass die Adresse des VPN-Servers zum veröffentlichten Dienst erlaubt wird, und trotzdem fällt die Verbindung. Dieses Ergebnis ist verbreitet und kein Docker-Fehler. Zwei getrennte Treffer sind falsch: Die Quelle, die Sie geschrieben haben, muss nicht die Quelle sein, die der Host empfängt, und der Port, den Sie geschrieben haben, muss nicht der Port sein, den der Filter sieht. Beides zu korrigieren erfordert einen Blick auf den Paketpfad statt auf das Dienstschema.
Der Mythos: VPN-Server erlauben, und fertig
Ein geroutetes VPN kann die Tunneladresse des Clients bis zum Docker-Host erhalten. Ein Gateway, das Quellübersetzung durchführt, kann diese Adresse durch seine eigene ersetzen. Beide Entwürfe sind zulässig, und sie erzeugen unterschiedliche Quellen für dieselbe Benutzeraktion.
Der Ausdruck VPN-Server-IP beschreibt also eine Annahme, keine Beobachtung. Solange Sie nicht wissen, welcher der beiden Entwürfe vor Ihnen liegt, ist die Regel eine Vermutung.
Quelle: Client-Pool oder übersetztes Gateway
Prüfen Sie vier Dinge der Reihe nach. Erstens den Client-Adresspool, zum Beispiel 10.90.0.0/24. Zweitens, ob das Gateway diesen Pool übersetzt, bevor er den Host erreicht. Drittens die Quelle, die der Host für eine neue Verbindung tatsächlich beobachtet. Viertens, ob die Anwendungsauthentifizierung einzelne Benutzer unterscheidet, denn eine gemeinsame übersetzte Adresse kann das nicht.
Bleibt der Pool erhalten, verfehlt eine Regel, die nur die öffentliche Adresse des Gateways trifft, jeden Client. Übersetzt das Gateway bewusst, lässt die Erlaubnis der übersetzten Adresse jeden Benutzer dahinter herein, was für einen Dienst mit eigenem Login akzeptabel und für alles andere unakzeptabel sein kann.
Port: DNAT ändert die Zahl, die Sie treffen
Bei gewöhnlicher Linux-Bridge-Veröffentlichung mit Docker iptables wird eine Host-Zuordnung von 8443 auf Container-Port 443 übersetzt, bevor der Weiterleitungsfilter läuft. Das Paket erreicht den Filter mit Zielport 443. Eine Regel, die an dieser Stelle 8443 trifft, greift nie, obwohl 8443 das ist, was der Client eingegeben hat.
Der veröffentlichte Port existiert weiterhin im Verbindungs-Tracking, weshalb das ursprüngliche Ziel dort abgeglichen werden kann, wenn Sie es wirklich brauchen.
Entscheiden Sie, welche Zahl die Absicht ausdrückt. Treffen Sie den Container-Port nach DNAT, wenn die Regel den Dienst im Container schützt. Treffen Sie das ursprüngliche Ziel mit der conntrack-Option, wenn die Regel beschreiben muss, was der Client angefordert hat, und akzeptieren Sie die zusätzlichen Abgleichkosten und die Sorgfalt bei der Regelreihenfolge, die damit einhergehen.
Kette: DOCKER-USER, nicht INPUT
Dockers iptables-Leitfaden legt die Weiterleitungsrichtlinie für Benutzer in die Kette DOCKER-USER, die vor Dockers eigenen Weiterleitungsregeln ausgewertet wird. Eine aus einem Host-Dienst in die Kette INPUT kopierte Regel filtert Verkehr, der an den Host adressiert ist, nicht Verkehr, der in einen Container weitergeleitet wird. Dieser Fehler erzeugt eine Regel, die richtig aussieht und keine Wirkung auf den Containerpfad hat.
Halten Sie Quellbereich, effektiven Zielport, Protokoll und eingehende Schnittstelle in derselben Regel zusammen. Eine reine Quellfreigabe für jedes weitergeleitete Ziel ist weiter gefasst als die Freigabe eines veröffentlichten Dienstes.
Mit frischen Verbindungen prüfen
Testen Sie beide Richtungen mit neuen Verbindungen: ein erlaubter VPN-Client und eine Quelle, die abgelehnt bleiben soll. Bestehender Verbindungszustand kann eine Sitzung am Leben halten, nachdem die Richtlinie geändert wurde, eine alte Verbindung beweist also nichts über die neue Regel. Prüfen Sie danach den Antwortpfad, denn der Container muss weiterhin zurückschleifen zu der Quelle, die er sieht.
Der iptables-Leitfaden von Docker dokumentiert die Kettenreihenfolge und das Portübersetzungsverhalten hinter diesen Prüfungen. Lesen Sie ihn, bevor Sie ein Rezept kopieren, und bestätigen Sie, welches Backend das installierte Docker verwendet, denn das nftables-Backend bindet Richtlinien anders ein.