Welche Adresse gehört im DNS zu einem per VPN verbundenen Server?

Ein gehosteter Server mit installiertem VPN hält am Ende drei Adressen, und nur eine davon gehört an jede Stelle, die du gerade konfigurieren willst. Die Nummer aus einem Provider-Dashboard in DNS, in einen Listener oder in eine Allowlist zu kopieren, ist der Weg, auf dem aus einem funktionierenden Tunnel ein Dienst wird, den niemand erreicht. Dieses Runbook ordnet die Arbeit so, dass jede Adresse für einen genannten Zweck gewählt wird. Es listet außerdem die Befehle auf, die bestätigen, was du tatsächlich veröffentlicht hast.

Ordne die drei Adressen zu, bevor du etwas veröffentlichst

Benenne sie nach ihrer Funktion. Die Underlay-Adresse ist das, was die Maschine nutzt, um den VPN-Endpunkt über das Internet zu erreichen, und sie ist hinter dem NAT des Providers oft privat. Die Tunneladresse lebt innerhalb des VPN und wird je nach Produkt vom Server oder vom Client vergeben. Der öffentliche Ausgang ist die Adresse, die eine entfernte Website nach der Übersetzung protokolliert, und er muss auf keiner Schnittstelle existieren, die du abfragen kannst.

Ein Dashboard, das eine öffentliche Adresse für eine Maschine zeigt, sagt dir sehr wenig über die anderen beiden Rollen. Underlay-Erreichbarkeit ist eine Voraussetzung, kein Kauf: Ein Laptop hinter einem Heimrouter kann einen gehosteten VPN-Endpunkt erreichen, ohne eine öffentliche IPv4-Adresse zu besitzen. Was du nicht kannst, ist einen eingehenden Pfad zu erfinden, indem du einen Namen schreibst, der auf eine Adresse auflöst, die niemand weiterleitet.

Wähle die Adresse nach dem Dienst, nicht nach dem Etikett

Schreibe auf, was der Server tun muss, bevor du eine Nummer wählst. Ausgehende API-Aufrufe brauchen einen stabilen Ausgang, wenn die Gegenseite eine Allowlist führt. Privater Zugriff braucht eine Tunneladresse, zu der Clients routen können, und einen daran gebundenen Listener. Öffentliches Hosten braucht eine eingehende Zuordnung, die der Provider tatsächlich anbietet, und die liefert die Ausgangsadresse allein nicht.

Eine einzige Maschine kann alle drei Zwecke bedienen und trotzdem drei verschiedene Adressen nutzen. Was bricht, ist die Annahme, dass ein Wert sie alle abdeckt:

Die eingehende Zeile ist die, über die Leute streiten. Ein Record, der auf die Ausgangsadresse zeigt, erzeugt keinen Listener, keine Firewall-Öffnung und kein Port-Mapping, und Warten ändert daran nichts. Wenn der Provider eine dedizierte Adresse zusammen mit einer eingehenden Regel verkauft, ist dieses Bündel die Fähigkeit, die du gekauft hast; die Adresse allein ist nicht der Anspruch.

Befehle, die zeigen, welche Adresse welche ist

Lies die Maschine, nicht das Dashboard. Schnittstellennamen unterscheiden sich zwischen Systemen, also ordne Adressen den Geräten zu, statt einem Etikett zu vertrauen.

Die erste Zeile listet jede IPv4-Adresse und ihr Gerät, und die zweite fragt den Kernel, welches Gerät er für ein bekanntes Ziel außerhalb verwenden würde:

ip -brief -4 addr show
ip -4 route get 198.51.100.10
curl -4 -s https://ifconfig.me
ss -lntp | grep -E ':(443|1194)'

Antwortet die Routenabfrage für öffentlichen Verkehr mit einem Tunnelgerät, ist dein Full Tunnel in Kraft. Die Listener-Prüfung ist genauso wichtig, denn ein Prozess, der nur an 127.0.0.1 gebunden ist, wird nie auf der Tunneladresse antworten, egal welchen Namen du veröffentlichst.

Veröffentliche sie, dann prüfe von außen

Veröffentliche den Wert, den der Dienst braucht, und nichts mehr: einen A- oder AAAA-Record fürs Hosten, einen Allowlist-Eintrag für ausgehende Aufrufe, ein Clientprofil für privaten Zugriff. Teste dann von der Position aus, auf die es ankommt, und das ist nie die Maschine, die du gerade bearbeitet hast.

Zwei Prüfungen decken das meiste ab, und beide sind billig genug, um sie in einem Skript zu behalten:

dig +short vpn.example.net A
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://vpn.example.net/health

Eine DNS-Antwort, die beweist, dass dein Record existiert, ist kein Beweis dafür, dass eine Anfrage ankommt, und eine erfolgreiche Anfrage beweist nur, dass ein Pfad von einem Netz aus funktioniert. Wiederhole die Prüfung über eine Mobilverbindung, wenn eine Allowlist im Spiel ist, denn der Ausgang, den du beobachtest, kann von der Adressfamilie und der genommenen Route abhängen. Notiere, welche Familie du verifiziert hast; ein funktionierender IPv4-Pfad sagt überhaupt nichts über IPv6 aus.

Ist der Dienst eingehend, reicht die Ausgangsadresse nicht

Eingehender Zugriff braucht vier Dinge in einer Reihe: einen Namen oder eine Adresse, die ein Client erreichen kann, eine Route, die das Paket zur Maschine bringt, einen Listener, der es annimmt, und eine Richtlinie, die es nicht verwirft. Ein VPN ändert das zweite Element und manchmal das erste, und für das dritte und vierte tut es nichts. Wenn der Tunnel der Zustellpfad ist, verbinden sich Clients mit der Tunneladresse, nicht mit dem Ausgang.

Halte fest, von welcher Adresse jeder Dienst abhängt, und sieh diesen Eintrag erneut an, wann immer der Provider sein Routingmodell ändert. Ein Server, der privat antwortet und öffentlich scheitert, ist meist nicht kaputt; er antwortet unter der falschen Identität, und die Reparatur ist eine Mapping-Entscheidung und keine Firewall-Änderung.