Warum ein SRV-Eintrag nur einem Client hilft, der ihn selbst abfragt

Ein SRV-Eintrag in Ihrer Zone lehrt keinen VPN-Client, ihn abzufragen. Der Client muss das Label kennen, sich zum Senden der Abfrage entscheiden und auf das reagieren, was zurückkommt, und DNS kann die ersten beiden davon nicht liefern. Die meisten gescheiterten SRV-Pläne sind daher Client-Probleme in DNS-Kostüm. Lesen Sie zuerst das Discovery-Verhalten des Clients und veröffentlichen Sie dann nur das Label, das er tatsächlich abfragt.

Ein Eintrag, den niemand abfragt, kann niemandem helfen

SRV veröffentlicht den Standort eines Dienstes; er kündigt ihn nicht an. Nichts schiebt einen Eintrag auf einen Client zu, und kein Resolver bietet einen Namen an, nach dem nie gefragt wurde. Die Suche beginnt damit, dass die Anwendung sie beschließt, also muss das Label aus der Produktdokumentation oder aus der Beobachtung der Software im Netz stammen. Wo der Client keinen Discovery-Schritt hat, ändert ein Eintrag die Zone und sonst nichts.

Deshalb kann ein Produkt in einem Netz zu funktionieren beginnen, während ein anderes von derselben Änderung unberührt bleibt. Die Variable ist die Software, und der DNS-Server tut genau das, was ihm gesagt wurde. Lesen Sie die Zone nach der Änderung auch zurück, denn ein falsch getipptes Label versteckt sich leicht zwischen Einträgen, die alle gleich aussehen.

Lesen Sie die Felder, bevor Sie sie schreiben

Ein Eintrag trägt vier Werte, und jeder beantwortet eine andere Frage: Die Priorität ordnet die Ziele, die ein Client versuchen darf, die Gewichtung verteilt die Last zwischen Zielen gleicher Priorität, der Port benennt den Transportport, und das Ziel benennt den Host. Die Spezifikation erlaubt außerdem ein Ziel von ., um zu bedeuten, dass der Dienst absichtlich nicht verfügbar ist, was eine nützliche Antwort und keine kaputte ist.

Keines dieser Felder trägt Anmeldedaten, eine Zertifikatsrichtlinie oder eine Anwendungsversion, und ein Client, der die Gewichtung ignoriert, verbindet trotzdem, nur ohne die beabsichtigte Balance. Das Ziel braucht eigene Adresseinträge, und es sollte ein kanonischer Name und kein Alias sein. Ein Eintrag, der auf einen Host ohne Listener zeigt, erzeugt einen Verbindungsfehler, der wie ein DNS-Fehler aussieht, und das ist die teuerste Art der Irreführung. Veröffentlichen Sie die ganze Kette oder nichts davon.

Finden Sie das Label, das der Client tatsächlich sendet

Bestimmen Sie das Label aus Belegen statt aus einer Vermutung über den Produktnamen. Entweder nennt die Dokumentation den Dienstnamen, oder ein Mitschnitt zeigt die Abfrage, die den Client beim Start verlässt. Beide Wege enden am selben Punkt: ein exakter Name und Typ zum Testen gegen den Resolver.

dig +short SRV _vpn._tcp.gw.example
dig +short A edge2.gw.example
tcpdump -ni any udp port 53

Vergleichen Sie die Antwort Zeichen für Zeichen mit dem veröffentlichten Eintrag, denn die Unterstriche und der Punkt am Ende gehören zum Namen. Eine leere Antwort auf eine tatsächlich gesendete Abfrage deutet auf die Zone, während gar keine Abfrage auf den Client deutet, und diese Befunde schicken Sie zu verschiedenen Teams. Eine echte Antwort sieht aus wie die Zeile unten, wo Priorität 20 gegen jeden Eintrag mit niedrigerer Priorität verliert und der Client Port 8443 am genannten Ziel wählt.

_vpn._tcp.gw.example. 600 IN SRV 20 10 8443 edge2.gw.example.

Das Ziel muss ebenfalls existieren

Ein Ziel, das sich auflösen lässt, ist nicht dasselbe wie ein Dienst, der antwortet. Prüfen Sie die Adresseinträge für das Ziel und prüfen Sie dann, ob auf dem veröffentlichten Port und Protokoll etwas lauscht. Ein TCP-Eintrag, der auf einen reinen UDP-Listener zeigt, ist eine Unstimmigkeit, die keine Zonenbearbeitung repariert. Halten Sie die TTL kurz, solange das Ziel im Fluss ist, und verlängern Sie sie, sobald der Name aufhört, sich zu bewegen.

Clients, die Discovery tatsächlich umsetzen, unterscheiden sich darin, wie viel des Eintrags sie beachten. Manche nutzen nur die Priorität, manche behandeln die Gewichtung als Empfehlung, und einige ignorieren den Port und nehmen einen Standard an. Diese Unterschiede gehören in Ihre Notizen neben dem Label, denn sie erklären Verhalten, das sonst wie ein Resolverfehler aussieht.

Discovery ist keine Authentifizierung

Eine SRV-Antwort sagt, wohin man sich verbindet, und sie sagt nichts darüber, wem man nach der Ankunft vertraut. Lassen Sie die Zertifikatsprüfung und die Server-Identitätsprüfungen des Clients genau so, wie sie waren, denn ein Eintrag, den jemand anderes fälschen kann, darf keine Vertrauensentscheidung werden. DNS-Antworten sind cachebar und von jedem bearbeitbar, der die Zone kontrolliert, was sie zu einem schlechten Ort für eingebettete Richtlinien macht.

Für einen Client ohne Discovery-Unterstützung verteilen Sie das Profil oder die Gateway-URL, die er akzeptiert, und notieren Sie, welches Produkt welche Methode nutzt. Diese Notiz hindert den nächsten Administrator daran, einen Eintrag hinzuzufügen und zu erwarten, dass er überall funktioniert. Die SRV-Spezifikation beschreibt die Auswahl zwischen Zielen, und sie als Autorisierungsmechanismus zu lesen, ist der Weg, auf dem ein hilfreicher Eintrag zu einer Sicherheitsannahme wird. Veröffentlichen Sie bewusst, benennen Sie das Label in Ihrer Dokumentation, und behandeln Sie den Client als die Komponente, die entscheidet, ob all das Bedeutung hat.