Meshnet, Docker und die Berechtigung dazwischen

Zwei URLs können im Browser eines Peers identisch aussehen und für die Firewall völlig Verschiedenes bedeuten. Die eine zeigt auf einen Dienst, der auf dem Host selbst lauscht. Die andere zeigt auf eine Host-Adresse, deren Port in ein Container-Netzwerk veröffentlicht ist, wo ein Übersetzungsschritt die Verbindung an eine andere IP übergibt. In einem Peer-to-Peer-Mesh, das den Zugriff auf das lokale Netzwerk mit einer Berechtigung pro Peer steuert, ist dieser Unterschied die gesamte Prüfung.

Die Berechtigung betrifft den Host-Endpunkt, die Übersetzung betrifft Docker, und die Anmeldung betrifft die Anwendung. Drei Entscheidungen, drei Stellen zum Nachsehen.

Verfolgen Sie das Ziel nach der Veröffentlichung

Nehmen Sie einen Linux-Docker-Host, der Port 80 eines Containers auf Host-Port 8080 veröffentlicht. Ein Peer verbindet sich mit der Mesh-Adresse des Hosts auf 8080, der Host nimmt die Verbindung an, und eine Zielübersetzung schreibt sie auf die Bridge-Adresse des Containers um, typischerweise so etwas wie 172.17.0.2 auf Port 80.

Bis eine Regel diesen Fluss prüft, ist das interessante Ziel der Container, nicht der Host. Eine Richtlinie, die nur über »einen Dienst auf dieser Maschine« nachdenkt, denkt über das falsche Objekt nach. Die Anfrage landete auf dem Host, aber sie wird woanders ausgeliefert.

Deshalb führt die Mesh-Dokumentation Docker-Container unter den Ressourcen auf, die die Berechtigung für das lokale Netzwerk unter Linux regelt. Die Berechtigung ist kein Synonym für einen gewöhnlichen Eintrag in einer VPN-Allowlist, und die beiden Kontrollen ersetzen einander nicht. Die eine entscheidet, ob ein Peer lokale Ressourcen überhaupt erreichen darf; die andere entscheidet, welche Ziele eine getunnelte Route trägt.

Entscheiden Sie, wie viel lokalen Zugriff eine Berechtigung gewährt

Einem Peer Zugriff auf das lokale Netzwerk zu gewähren, ist keine Entscheidung über einen einzelnen Container. Es kann andere veröffentlichte Dienste auf demselben Host freilegen, und es kann je nach Weiterleitung des Hosts weiter reichen. Prüfen Sie den effektiven Umfang, bevor Sie den Schalter für ein Dashboard umlegen.

Sehen Sie dann nach, wo Docker den Port veröffentlicht. Eine Veröffentlichung auf 0.0.0.0 erzeugt einen Listener auf jeder Host-Adresse, was einen gewöhnlichen LAN-Eintrag neben dem Mesh-Eintrag hinzufügen kann. Wenn die Anforderung nur Mesh ist, binden Sie die Veröffentlichung an die bestimmte Adresse oder Schnittstelle, die Sie meinen, und behandeln Sie die breitere Bindung als eigenen Befund statt als Bequemlichkeit.

Halten Sie die Weiterleitungsrichtlinie des Hosts und die eigene Authentifizierung der Anwendung eng genug für den Dienst. Eine privat wirkende URL ist keine Zugriffskontrolle, und ein Container, der jeder Quelle in seinem Bridge-Netz vertraut, ist nicht dadurch geschützt, dass der Mesh-Peer genehmigt wurde. Die Authentifizierung der Anwendung ist die dritte Entscheidung, und sie ist die einzige, die weiß, wer der Benutzer ist. Eine Berechtigung auf Host-Ebene kann dieses Wissen nicht liefern.

Testen Sie die Berechtigung, nicht nur die URL

Öffnen Sie vom genehmigten Peer aus den genauen Dienst und bestätigen Sie, dass er funktioniert. Versuchen Sie dann ein Ziel, das verweigert bleiben sollte, und bestätigen Sie, dass es nicht funktioniert. Nur den glücklichen Pfad zu testen, sagt Ihnen, dass die Berechtigung erteilt wurde; es sagt Ihnen nicht, dass die Grenze dort liegt, wo Sie denken.

Vergleichen Sie einen hosteigenen Dienst getrennt. Wenn eine Datenbank auf dem Host lauscht und ein Dashboard in einem Container läuft, folgen sie unterschiedlichen Wegen durch dieselbe Berechtigung und werden möglicherweise nicht gleich von der Weiterleitungsrichtlinie des Hosts geregelt. Notieren Sie, was was ist, bevor Sie die Prüfnotiz schreiben.

Leeren Sie nicht Dockers Tabellen oder die Regeln des Mesh-Clients, um Zugriff zu »zurücksetzen«. Beide Produkte installieren ihre eigene Richtlinienintegration, und sie zu löschen erzeugt einen Host, der zu funktionieren scheint, während er die Kontrollen umgeht, die Sie bewerten sollten. Wenn eine Regel falsch aussieht, lesen Sie sie und ändern Sie genau diese Regel. Wenn Sie nicht erklären können, was eine Regel tut, ist das der Befund, kein Grund, sie zu löschen.

Schreiben Sie den Befund in den Begriffen des Systems selbst

Wichtig ist die Unterscheidung, die das Produkt tatsächlich durchsetzt, nicht die in der Prüfvorlage: die Berechtigung, einen Host-Endpunkt zu erreichen, die Berechtigung, geroutete private Ressourcen zu erreichen, und die Berechtigung, die Anwendung zu nutzen. Einen Port zu veröffentlichen lässt diese drei Entscheidungen genau dort, wo sie waren, und wer sie als eine behandelt, genehmigt den falschen Umfang.

Nennen Sie die Host-Adresse, den veröffentlichten Port, das Container-Ziel und die Peer-Berechtigung im selben Satz. Dieser Satz ist von jemand anderem prüfbar, und das macht ihn zu einem Befund statt zu einer Meinung.