Så konfigurerar du split-horizon-DNS för intern och fjärråtkomst till appar

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

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

Använd samma värdnamn för applikationen överallt, men returnera en privat proxyadress till betrodda interna klienter och VPN-klienter och den offentliga slutpunkten eller tunneländpunkten till externa klienter. Behåll TLS-namnet identiskt på båda vägarna.

Split-horizon-DNS är värdefullt när hairpin-NAT inte är tillgängligt eller när lokal trafik bör stanna på LAN-nätverket. Det fungerar inte när klienter kringgår den avsedda resolvern, gamla svar finns kvar eller den interna slutpunkten använder ett annat certifikat. Definiera de två vyerna, sänk TTL-värdena före migreringen och testa namnuppslagning separat från HTTPS.

Definiera de interna och externa vyerna

Välj ett FQDN för varje applikation. I offentlig DNS pekar du det mot den externt nåbara proxyn, tunneln eller gatewayen. I intern DNS skriver du över det med den lokala proxyns privata adress.

Skapa inte ett annat internt värdnamn enbart för att undvika certifikatarbete, såvida inte applikationen stöder två kanoniska URL:er. Ett namn håller bokmärken, callback-adresser och mobilklienter konsekventa vid nätverksbyten.

Dokumentera vilka subnät som får den interna vyn. Gästnätverk kan behöva det offentliga svaret, medan betrodda LAN- och fjärranslutna VPN-klienter får det privata svaret via sin tilldelade resolver.

Gör valet av resolver deterministiskt

Annonsera den interna resolvern via DHCP och via VPN-profilen. Fråga den uttryckligen först och fråga sedan via operativsystemet för att upptäcka en lokal cache eller en förbikoppling av krypterad DNS.

Resolvercache och olika DNS-bibliotek kan ge överraskande resultat. Den här katalogen över vanliga DNS-felmoder förklarar varför en ändring hos den auktoritativa DNS-servern kanske inte visas direkt hos klienten.

Rensa endast de relevanta cacharna efter att du har bekräftat att posten är korrekt vid källan. Om en hanterad webbläsare använder en egen krypterad resolver ska du antingen tillämpa en godkänd policy eller acceptera den offentliga vägen i stället för att upprepade gånger redigera den lokala zonen.

Samordna proxy, certifikat och applikationens beteende

Båda slutpunkterna måste presentera ett certifikat som är giltigt för det gemensamma FQDN:et och dirigera värdnamnet till samma applikationsidentitet. En certifikatvarning innebär att DNS nådde en slutpunkt, men att slutpunkten inte är konfigurerad för det begärda namnet.

Verifiera omdirigeringar, WebSockets, callback-URL:er och applikationens externa URL. En lokal proxy som omdirigerar till en IP-adress eller ett annat värdnamn förstör designen med ett enda namn.

Om applikationen använder en undersökväg ska du hålla dess bas-URL och proxyrutt synkroniserade. ZimaSpace-checklistan för uppgraderingar av Jellyfin-containrar hjälper dig att bevara proxy-, monterings- och URL-inställningar före en ändring.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Testa övergångar mellan intern och fjärråtkomst

På Wi-Fi ska du notera DNS-servern, den returnerade adressen, certifikatet och applikationens resultat. Upprepa på mobilnätet med Wi-Fi inaktiverat. Adressen bör ändras medan värdnamnet och certifikatidentiteten förblir desamma.

Anslut VPN:et från ett externt nätverk och upprepa testet. Om VPN:et ska använda den privata vägen men får det offentliga svaret ska du åtgärda dess DNS-tilldelning eller routning innan du ändrar applikationsinställningarna.

Flytta slutligen en klient mellan nätverk och vänta ut TTL-värdet. Avsluta när alla tre vägarna är deterministiska. Ta bort den interna överskrivningen om klienter når fel proxy eller om du inte kan kontrollera vilken resolver de använder.