Vorlage: VPN-Endpunkt mit stabilem Hostnamen
Eine lesbare Adresse für einen bewusst freigegebenen VPN-Dienst.
Verwendung der Demo
Alle example.com-Namen, .example-Ziele und öffentlichen Beispieladressen sind Dokumentationswerte. Diese Vorlagen ändern keine DNS-Zone automatisch. Ersetze sie mit deinen tatsächlichen Werten und prüfe die Voraussetzungen des Dienstes. Private Adressen in internen Beispielen gehören nur in die interne DNS-Zone.
Öffentliches DNS-Gerüst
vpn.example.com. 300 IN A 198.51.100.60Ersetze die Dokumentationsadresse durch die tatsächliche öffentliche IP des VPN-Endpunkts. Ein Port wird in der VPN-Konfiguration gesetzt, nicht im A-Record. Ein gewöhnlicher HTTP-Proxy gehört nicht vor einen beliebigen UDP-VPN-Dienst.
Dynamische IP berücksichtigen
Wenn die öffentliche Adresse regelmäßig wechselt, brauchst du einen abgestimmten Aktualisierungsprozess beim DNS-Anbieter. Eine niedrige TTL allein entdeckt keine neue IP. Der Aktualisierer benötigt eng begrenzte Zugangsdaten und darf nicht unbeabsichtigt andere Zonen verändern. Prüfe außerdem, ob der Anschluss eine eigene erreichbare öffentliche Adresse oder nur Provider-NAT hat.
Zugriff auf interne Namen
Der öffentliche VPN-Hostname dient dem Verbindungsaufbau. Nach der Verbindung kann der Client einen internen Resolver für pve1.mgmt.example.com oder andere interne Dienste verwenden. Welche DNS-Server und Routen an den Client gelangen, ist eine VPN-Einstellung. Der öffentliche A-Record löst diese Aufgabe nicht.
Sicherheit und Test
Öffne nur den tatsächlich vorgesehenen VPN-Port und verwalte Schlüssel beziehungsweise Konten im VPN-System. Teste einen Verbindungsaufbau aus einem fremden Netz, anschließend interne Namensauflösung und erlaubte Routen. Entferne verlorene Gerätezugänge im VPN-System. DNS kann diese Geräte nicht authentifizieren oder widerrufen.