Privater DNS-Name oder nur eine IP? Entscheiden Sie, bevor Sie ihn teilen

Zwei Fragen vermischen sich, wenn ein privater Dienst für entfernte Nutzer geöffnet wird. Die erste ist, welchen Namen Clients verwenden sollen; die zweite, welche Quellen der Dienst zulassen soll. Beantworten Sie sie in dieser Reihenfolge, denn ein richtiger Name hinter der falschen Zugriffsregel scheitert trotzdem, und eine richtige Regel hinter einem Namen, der nicht aufgelöst wird, wird nie getestet.

Bedingung eins: Welchen Resolver-Pfad haben die Clients?

Ein privater Name funktioniert nur, wenn der Resolver des Clients ihn beantworten kann. Das heißt, ein autorisierter entfernter Client muss einen DNS-Server erreichen, der die Zone hält, entweder über den Tunnel oder über einen Resolver, den die Organisation bereits für entfernte Nutzer betreibt. Der Tunnel ist ein Transportmittel, kein Verzeichnis. Er gibt dem Client einen Pfad zu einem Resolver und sagt ihm nicht, welche Zone er abfragen soll.

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

Ein öffentlicher Resolver lernt keine private Zone, nur weil der Laptop mit einem VPN verbunden ist.

Das Suffix verdient dieselbe Aufmerksamkeit. Verwenden Sie eine Subdomain einer Domain, die die Organisation kontrolliert, damit Eigentümerschaft und Zertifikatsplanung eindeutig bleiben. Vermeiden Sie .local: die Multicast-DNS-Spezifikation bindet dieses Suffix an Link-Local-Auflösung, und ein gerouteter Tunnel bildet dieses Verhalten nicht für Sie nach.

Bedingung zwei: Welche Quelle empfängt der Dienst?

Zugriffsregeln werden gegen Adressen geschrieben, daher ist die nützliche Frage, welche Adresse der Dienst nach Routing und Übersetzung sieht. Für einen Beispieldienst unter 10.20.30.40 kommen Büro-Clients aus 10.20.30.0/24 und entfernte Clients aus einem separaten Pool wie 10.99.0.0/24.

Übersetzt ein Gateway den entfernten Pool, sieht der Dienst den Übersetzer, und eine für 10.99.0.0/24 geschriebene Regel passt nicht.

Lesen Sie dies von der Dienstseite statt von der Clientseite. Ein Listener-Log oder ein Paketmitschnitt auf dem Diensthost zeigt die Quelle, die tatsächlich ankam; die eigene Adresse des Clients ist nur eine Vermutung darüber, was den Pfad überlebt hat.

Bedingung drei: Ist der Name an einen Dienst oder an einen Host gebunden?

Ein Name, der auf die Adresse einer Maschine zeigt, koppelt jeden Client an diese Maschine. Ein Name, der auf einen Load Balancer oder eine stabile Dienstadresse zeigt, übersteht den Austausch des dahinterliegenden Hosts. Wählen Sie bewusst, denn eine spätere Änderung bedeutet, die Lesezeichen jedes Clients und den Betreff jedes Zertifikats zu ändern.

Für einen einzelnen internen Dienst ist ein direkter Eintrag meist in Ordnung und einfacher zu durchdenken.

Für alles, was ersetzt, neu aufgebaut oder skaliert wird, ist ein stabiles Frontend die zusätzliche Konfiguration wert. Der Test ist einfach: Wenn Sie das Backend ersetzen können, ohne es den Nutzern zu sagen, ist der Name an den Dienst gebunden; wenn nicht, ist er an einen Host gebunden.

Testen Sie die beiden Entscheidungen getrennt

Lösen Sie zuerst auf, verbinden Sie sich dann. Ein Auflösungstest, der die erwartete Adresse zurückgibt, beweist den Namenspfad und sagt nichts über den Zugriff. Ein Verbindungstest beweist Pfad und Regel zusammen, führen Sie ihn also erst nach erfolgreicher Auflösung aus.

curl -sv --max-time 5 https://files.corp.example/health

Testen Sie dann einmal eine verbotene Quelle und dokumentieren Sie das Ergebnis.

Halten Sie die beiden Aufzeichnungen in Ihrer Dokumentation getrennt: den Namen und seine Zone, die zugelassenen Quellen und den Eigentümer der Regel. Wenn sich das eine ändert, muss das andere nicht.

Wo die Entscheidung meist schiefgeht

Der häufige Fehler ist ein Dienst, der unter einem Namen veröffentlicht wird, der nur im Büronetz auflöst, mit einer Zugriffsregel, die nur den Bürobereich zulässt. Entfernte Nutzer melden dann einen defekten Dienst, der in Wahrheit aus zwei getrennten Auslassungen besteht. Der zweite häufige Fehler ist der umgekehrte: eine breite Zugriffsregel, hinzugefügt, um ein Namensproblem zu beseitigen, lässt den Dienst von Quellen erreichbar, die niemand beabsichtigt hat. Beides sind Konfigurationsauslassungen, und vom Stuhl des Nutzers sehen sie gleich aus.

Keiner der Fehler ist aus einem einzigen erfolgreichen Test sichtbar. Deshalb verdienen die beiden Entscheidungen getrennte Aufzeichnungen und getrennte Tests, selbst wenn dieselbe Person beide trifft.

Schreiben Sie beides auf, bevor der Dienst live geht, denn die nächste Änderung wird leichter zu durchdenken sein. Die Aufzeichnung ist kurz: eine Zeile für den Namen und seine Zone, eine Zeile für die zugelassenen Quellen und den Eigentümer der Regel.