Så konfigurerar du lokala DNS-överskrivningar för flera omvända proxyservrar

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

Skapa en auktoritativ lokal mappning för varje applikationsnamn och peka den mot exakt en reverse proxy-adress per klientnätverk. Skapa inte konkurrerande wildcard-överskrivningar på flera DNS-servrar.

Flera proxyservrar blir förvirrande när samma publika domän återanvänds internt: en bärbar dator kan fråga routern, en container kan fråga en lokal resolver och en telefon kan använda krypterad DNS. Resultatet kan se ut som ett proxy- eller certifikatfel trots att klienten helt enkelt fick fel adress. Inventera namnen, resolverservrarna, proxylyssnarna och certifikaten innan du lägger till poster.

Tilldela namn till proxygränser

Lista varje applikations-FQDN och den proxy som terminerar dess TLS-anslutning. Använd specifika poster för undantag och reservera ett wildcard endast för en domän vars hela namnrymd tillhör en proxy.

Undvik att ge samma namn två privata A-poster såvida inte båda proxyservrarna avsiktligt är aktiva och identiskt konfigurerade. DNS returnerar adresser, inte tjänstestatus, så tillfälliga round-robin-poster kan skicka hälften av klienterna till en proxy som saknar routen eller certifikatet.

Håll administrativa namn åtskilda från användarnamn. Om ett administratörs-hostnamn aldrig får lösas upp på ett gästnätverk ska du placera det i en vy eller resolver som endast är tillgänglig för det betrodda VLAN:et i stället för att förlita dig på att proxyn döljer det senare.

Placera överskrivningar i den resolver som klienterna faktiskt använder

Skapa den lokala zonen eller värdöverskrivningarna på den DNS-tjänst som annonseras av DHCP för nätverket. Peka varje applikationsnamn mot LAN-adressen till dess proxy, inte mot applikationscontainern och inte automatiskt mot den publika WAN-adressen.

Klienter och applikationer kan använda olika resolverbibliotek och cacheminnen, vilket är anledningen till att DNS-beteendet kan förbli dolt. Kontrollera servern som visas i frågeutdata i stället för att anta att routerns överskrivning användes.

Inaktivera eller ta hänsyn till klientbaserad krypterad DNS under testet. Om klienten avsiktligt kringgår lokal DNS kan split-horizon-överskrivningar inte påverka den; välj i stället en hanterad DNS-policy, en publik post plus hairpin-routing eller en VPN-tillhandahållen resolver.

Matcha proxyrutter, TLS och applikations-URL:er

Konfigurera endast de värdnamn som tilldelats varje proxy och bekräfta att certifikatet täcker dessa namn. Ett korrekt DNS-svar följt av fel certifikat bevisar att trafiken nådde en lyssnare, men inte att den avsedda virtuella värden användes.

Testa upstream-routen från själva proxyn och testa sedan det publika värdnamnet från en klient. Om direkt åtkomst till upstream fungerar men värdnamnet returnerar en standardsida ska du korrigera proxyns värdmatchning innan du ändrar DNS igen.

För applikationer som ligger under en sökväg ska proxyrouten och applikationens bas-URL hållas synkroniserade. ZimaSpace-guiden om att ta bort Jellyfin-exponering på ett säkert sätt visar också varför DNS, proxyrutter, vidarebefordran och ACL:er måste spåras tillsammans.

Featured

ZimaCube 2 personlig molnhem NAS

ZimaCube2

Verifiera varje nätverk och definiera återställning

Fråga FQDN:et direkt mot den avsedda lokala resolvern och fråga sedan via operativsystemets normala sökväg. Båda svaren ska peka på samma proxy för det nätverket, och TTL-värdet ska följa den lokala policyn.

Öppna applikationen från det betrodda LAN:et, gäst- eller medie-VLAN:et samt VPN:et när det är tillämpligt. Registrera den upplösta adressen, certifikatnamnet, HTTP-statusen och den slutliga omdirigeringen; dessa observationer visar om felet gäller DNS, TLS, proxyrouting eller applikationen.

Ta bort gamla dubblettposter först när alla klienter fungerar. Återställ den senaste överskrivningen om olika klienter växlar mellan proxyservrar, och sluta utöka wildcardet tills resolverloggarna visar vilken server som besvarade varje misslyckad begäran.