So konfigurierst du lokale DNS-Überschreibungen für mehrere Reverse-Proxys

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 Configure Local DNS Overrides for Multiple Reverse Proxies - Zima Store Online

Erstellen Sie für jeden Anwendungsnamen ein eindeutiges lokales Mapping und verweisen Sie es pro Clientnetzwerk auf genau eine Reverse-Proxy-Adresse. Erstellen Sie keine konkurrierenden Wildcard-Überschreibungen auf mehreren DNS-Servern.

Mehrere Proxys sorgen für Verwirrung, wenn dieselbe öffentliche Domain intern wiederverwendet wird: Ein Laptop fragt möglicherweise den Router, ein Container einen lokalen Resolver und ein Smartphone verwendet verschlüsseltes DNS. Das Ergebnis kann wie ein Proxy- oder Zertifikatsfehler aussehen, obwohl der Client einfach die falsche Adresse erhalten hat. Erfassen Sie die Namen, Resolver, Proxy-Listener und Zertifikate, bevor Sie Einträge hinzufügen.

Namen den Proxy-Grenzen zuweisen

Listen Sie jeden Anwendungs-FQDN und den Proxy auf, der seine TLS-Verbindung beendet. Verwenden Sie für Ausnahmen spezifische Einträge und reservieren Sie einen Wildcard-Eintrag nur für eine Domain, deren gesamter Namensraum zu einem einzigen Proxy gehört.

Vermeiden Sie es, demselben Namen zwei private A-Einträge zu geben, es sei denn, beide Proxys sind absichtlich aktiv und identisch konfiguriert. DNS liefert Adressen, nicht den Zustand eines Dienstes. Unüberlegte Round-Robin-Einträge können daher die Hälfte der Clients an einen Proxy senden, dem die Route oder das Zertifikat fehlt.

Halten Sie Verwaltungsnamen von benutzerseitig sichtbaren Namen getrennt. Wenn ein Administrations-Hostname in einem Gastnetzwerk niemals aufgelöst werden darf, platzieren Sie ihn in einer View oder einem Resolver, der nur für das vertrauenswürdige VLAN verfügbar ist, statt sich darauf zu verlassen, dass der Proxy ihn später verbirgt.

Überschreibungen im tatsächlich verwendeten Resolver hinterlegen

Erstellen Sie die lokale Zone oder die Host-Überschreibungen auf dem DNS-Dienst, der per DHCP für dieses Netzwerk bekanntgegeben wird. Verweisen Sie jeden Anwendungsnamen auf die LAN-Adresse des zuständigen Proxys, nicht auf den Anwendungskontainer und nicht automatisch auf die öffentliche WAN-Adresse.

Clients und Anwendungen können unterschiedliche Resolver-Bibliotheken und Caches verwenden. Deshalb kann das DNS-Verhalten verborgen bleiben. Überprüfen Sie den in der Abfrageausgabe angezeigten Server, statt anzunehmen, dass die Überschreibung des Routers verwendet wurde.

Deaktivieren Sie während des Tests clientseitig verschlüsseltes DNS oder berücksichtigen Sie es entsprechend. Wenn der Client das lokale DNS absichtlich umgeht, können Split-Horizon-Überschreibungen ihn nicht beeinflussen. Verwenden Sie stattdessen eine verwaltete DNS-Richtlinie, einen öffentlichen Eintrag mit Hairpin-Routing oder einen von einem VPN bereitgestellten Resolver.

Proxy-Routen, TLS und Anwendungs-URLs aufeinander abstimmen

Konfigurieren Sie auf jedem Proxy nur die ihm zugewiesenen Hostnamen und bestätigen Sie, dass das Zertifikat diese Namen abdeckt. Eine korrekte DNS-Antwort gefolgt vom falschen Zertifikat beweist, dass der Datenverkehr einen Listener erreicht hat, nicht jedoch den vorgesehenen virtuellen Host.

Testen Sie die Upstream-Route zunächst direkt vom Proxy aus und anschließend den öffentlichen Hostnamen von einem Client. Wenn der direkte Zugriff auf das Upstream-Ziel funktioniert, der Hostname jedoch eine Standardseite liefert, korrigieren Sie zuerst die Host-Zuordnung des Proxys, bevor Sie DNS erneut ändern.

Hosten Sie Anwendungen unter einem Pfad, müssen Proxy-Route und Basis-URL der Anwendung übereinstimmen. Der ZimaSpace-Leitfaden zum sicheren Entfernen der Jellyfin-Erreichbarkeit zeigt ebenfalls, warum DNS, Proxy-Routen, Weiterleitungen und ACLs gemeinsam erfasst werden müssen.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

Jedes Netzwerk überprüfen und einen Rollback definieren

Fragen Sie den FQDN direkt beim vorgesehenen lokalen Resolver ab und anschließend über den normalen Pfad des Betriebssystems. Beide Antworten sollten für dieses Netzwerk auf denselben Proxy verweisen, und die TTL sollte der lokalen Richtlinie entsprechen.

Öffnen Sie die Anwendung je nach Bedarf aus dem vertrauenswürdigen LAN, dem Gast- oder Medien-VLAN sowie über das VPN. Notieren Sie die aufgelöste Adresse, den Zertifikatsnamen, den HTTP-Status und die endgültige Weiterleitung. Diese Beobachtungen zeigen, ob ein Fehler bei DNS, TLS, dem Proxy-Routing oder der Anwendung liegt.

Entfernen Sie veraltete doppelte Einträge erst, wenn alle Clients erfolgreich getestet wurden. Machen Sie die zuletzt hinzugefügte Überschreibung rückgängig, wenn verschiedene Clients zwischen Proxys wechseln, und erweitern Sie den Wildcard-Eintrag nicht weiter, bis die Resolver-Protokolle belegen, welcher Server jede fehlerhafte Anfrage beantwortet hat.