Waardoor retourneert lokale DNS het juiste IP-adres, maar de verkeerde service?

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Lokale DNS kan het juiste NAS-IP-adres teruggeven, maar toch de verkeerde service openen wanneer de gedeelde reverse proxy de hostnaam naar een andere virtuele host doorstuurt.

Op een ZimaSpace-thuisserver kunnen meerdere apps één LAN-adres delen achter Nginx, Traefik, Caddy of een andere reverse proxy. DNS kiest alleen het bestemmings-IP-adres. De browser stuurt nog steeds een hostnaam mee via TLS SNI en de HTTP Host-header, waarna de proxy bepaalt welke container het verzoek ontvangt.

Controleer of het split-DNS-antwoord inderdaad bedoeld is

Vergelijk het lokale record met het openbare record en bevestig dat beide hostnamen naar dezelfde reverse proxy moeten verwijzen.

Een gerichte homelab-blog over split-DNS op split-DNS kan een privéroute teruggeven helpt deze mogelijkheid af te bakenen, omdat het probleem zelf wordt behandeld in plaats van alleen het onderliggende protocol te definiëren.

Laat de hostnaam in de browser ongewijzigd en verander alleen het adres dat door interne DNS wordt teruggegeven.

Bewijs dat de proxy op basis van de hostnaam routeert

Verstuur verzoeken met de verwachte hostnaam en vergelijk deze met rechtstreekse toegang via het IP-adres tot dezelfde NAS.

Een gerichte homelab-uitleg over reverse proxies op de Host-header selecteert de backend helpt deze mogelijkheid af te bakenen, omdat het probleem zelf wordt behandeld in plaats van alleen het onderliggende protocol te definiëren.

Als het rechtstreekse IP-adres een standaardapp opent terwijl de hostnaam de juiste app opent, ligt het probleem niet bij DNS; de routering van de virtuele host werkt dan zoals bedoeld.

Controleer of de Host-header wordt herschreven

Controleer de Host- en forwarded-host-headers bij de proxy en de backend.

Een gerichte uitleg over beveiliging en HTTP op wijzigingen aan de Host-header kunnen de routering aanpassen helpt deze mogelijkheid af te bakenen, omdat het probleem zelf wordt behandeld in plaats van alleen het onderliggende protocol te definiëren.

Corrigeer alleen de laag die de hostnaam herschrijft. Voeg geen dubbele DNS-records toe om een fout in de HTTP-routering te compenseren.

Controleer TLS SNI vóór de HTTP-routering

Meerdere HTTPS-apps op één IP-adres moeten nog steeds de hostnaam doorgeven die nodig is om het juiste certificaat en de juiste virtuele host te selecteren.

Een gerichte praktische SNI-handleiding op SNI selecteert tussen HTTPS-sites op één IP-adres helpt deze mogelijkheid af te bakenen, omdat het probleem zelf wordt behandeld in plaats van alleen het onderliggende protocol te definiëren.

Vergelijk de certificaatnaam met de backendroute. Een certificaat voor een andere app is een aanwijzing dat de selectie is misgegaan voordat het verzoek de bedoelde service bereikte.

Controleer de standaardvirtuele host

Als geen enkele hostnaamregel overeenkomt, sturen veel proxy's een standaardserver terug die bij een andere app kan horen.

Een gerichte Nginx-artikel over probleemoplossing op een niet-overeenkomende hostnaam kan de standaardserver bereiken helpt deze mogelijkheid af te bakenen, omdat het probleem zelf wordt behandeld in plaats van alleen het onderliggende protocol te definiëren.

Maak expliciete hostregels en een neutrale standaardreactie, in plaats van één toepassing als algemene opvang voor elk onbekend domein te laten fungeren.

Houd DNS-routering gescheiden van proxyroutering

Beschouw DNS als de selectie van een adres en de reverse proxy als de selectie van een toepassing.

Een gerichte uitleg over DNS versus reverse proxies op DNS en reverse proxies lossen verschillende routeringslagen op helpt deze mogelijkheid af te bakenen, omdat het probleem zelf wordt behandeld in plaats van alleen het onderliggende protocol te definiëren.

Test opnieuw met de exacte app-hostnaam vanaf een LAN-client. Het juiste resultaat bestaat uit het verwachte certificaat, de juiste proxyroute en de juiste backend, zonder bladwijzers met rechtstreekse IP-adressen.

Test het exacte thuisserverpad opnieuw

Herhaal na het wijzigen van één variabele dezelfde NAS- of self-hosted-workflow vanaf dezelfde client, in plaats van over te schakelen naar een andere test die mogelijk een ander pad gebruikt.

De gerelateerde ZimaSpace-handleiding op het aangrenzende thuisservernetwerkpad helpt om de laatste controle aan dezelfde self-hosted omgeving te koppelen.

De oplossing is pas voltooid wanneer het oorspronkelijke probleem ook na opnieuw verbinden, het herstarten van de service en een tweede gecontroleerde overdracht of aanvraag opgelost blijft.

Ondersteuning & Tips

Meer om te lezen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.