So richten Sie Split-Horizon-DNS für den internen und Remote-App-Zugriff ein

Eva Wong

IceWhale author

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

How to Set Up Split-Horizon DNS for Internal and Remote App Access - Zima Store Online

Verwenden Sie überall denselben Anwendungshostnamen, geben Sie jedoch vertrauenswürdigen internen Clients und VPN-Clients eine private Proxy-Adresse und externen Clients den öffentlichen oder Tunnel-Endpunkt zurück. Der TLS-Name muss für beide Pfade identisch bleiben.

Split-Horizon-DNS ist wertvoll, wenn Hairpin-NAT nicht verfügbar ist oder lokaler Datenverkehr im LAN bleiben soll. Es funktioniert nicht, wenn Clients den vorgesehenen Resolver umgehen, veraltete Antworten bestehen bleiben oder der interne Endpunkt ein anderes Zertifikat bereitstellt. Definieren Sie die beiden Ansichten, senken Sie vor der Migration die TTLs und testen Sie die Namensauflösung getrennt von HTTPS.

Interne und externe Ansichten definieren

Wählen Sie für jede Anwendung einen FQDN. Verweisen Sie ihn im öffentlichen DNS auf den extern erreichbaren Proxy, Tunnel oder Gateway; überschreiben Sie ihn im internen DNS mit der privaten Adresse des lokalen Proxys.

Erstellen Sie nicht einfach einen anderen, nur intern verwendeten Hostnamen, um die Zertifikatsarbeit zu vermeiden, es sei denn, die Anwendung unterstützt zwei kanonische URLs. Ein Name sorgt dafür, dass Lesezeichen, Callbacks und mobile Clients bei Standortwechseln konsistent bleiben.

Dokumentieren Sie, welche Subnetze die interne Ansicht erhalten. Gastnetzwerke benötigen möglicherweise die öffentliche Antwort, während vertrauenswürdige LAN- und Remote-Access-VPN-Clients über ihren zugewiesenen Resolver die private Antwort erhalten.

Resolver-Auswahl deterministisch gestalten

Veröffentlichen Sie den internen Resolver über DHCP und über das VPN-Profil. Fragen Sie zunächst explizit diesen Resolver ab und anschließend das Betriebssystem, um einen lokalen Cache oder eine Umgehung des verschlüsselten DNS zu erkennen.

Resolver-Caches und unterschiedliche DNS-Bibliotheken können zu überraschenden Ergebnissen führen; dieser Katalog häufiger DNS-Fehlermuster erklärt, warum eine autoritative Änderung beim Client möglicherweise nicht sofort sichtbar wird.

Leeren Sie nur die relevanten Caches, nachdem Sie bestätigt haben, dass der Eintrag an der Quelle korrekt ist. Wenn ein verwalteter Browser einen eigenen verschlüsselten Resolver verwendet, wenden Sie entweder eine genehmigte Richtlinie an oder akzeptieren Sie den öffentlichen Pfad, statt die lokale Zone wiederholt zu bearbeiten.

Proxy-, Zertifikats- und Anwendungsverhalten aufeinander abstimmen

Beide Endpunkte müssen ein für den gemeinsamen FQDN gültiges Zertifikat präsentieren und diesen Host derselben Anwendungsidentität zuordnen. Eine Zertifikatswarnung bedeutet, dass DNS einen Endpunkt erreicht hat, der Endpunkt jedoch nicht für den angeforderten Namen konfiguriert ist.

Überprüfen Sie Weiterleitungen, WebSockets, Callback-URLs und die externe URL der Anwendung. Ein lokaler Proxy, der auf eine IP-Adresse oder einen anderen Hostnamen weiterleitet, macht das Design mit einem einzigen Namen zunichte.

Wenn die Anwendung einen Unterpfad verwendet, müssen Basis-URL und Proxy-Route synchron bleiben. Die ZimaSpace-Checkliste für Jellyfin-Container-Upgrades hilft dabei, Proxy-, Mount- und URL-Einstellungen vor einer Änderung beizubehalten.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Übergänge zwischen internem und Remote-Zugriff testen

Notieren Sie im WLAN den DNS-Server, die zurückgegebene Adresse, das Zertifikat und das Anwendungsergebnis. Wiederholen Sie den Test über das Mobilfunknetz bei deaktiviertem WLAN; die Adresse sollte sich ändern, während Hostname und Zertifikatsidentität gleich bleiben.

Verbinden Sie das VPN von einem externen Netzwerk aus und wiederholen Sie den Test. Wenn das VPN den privaten Pfad verwenden soll, aber die öffentliche Antwort erhält, korrigieren Sie seine DNS-Zuweisung oder sein Routing, bevor Sie die Anwendungseinstellungen ändern.

Wechseln Sie abschließend mit einem Client zwischen Netzwerken und warten Sie die TTL ab. Beenden Sie den Vorgang erst, wenn alle drei Pfade deterministisch sind. Machen Sie die interne Überschreibung rückgängig, wenn Clients den falschen Proxy erreichen oder Sie nicht kontrollieren können, welchen Resolver sie verwenden.