Zo configureer je split-horizon-DNS voor interne en externe app-toegang

Eva Wong

IceWhale author

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.

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

Gebruik overal dezelfde hostnaam voor de applicatie, maar geef vertrouwde interne en VPN-clients een privéadres van de proxy en externe clients het openbare of tunnel-eindpunt. Houd de TLS-naam voor beide paden identiek.

Split-horizon-DNS is waardevol wanneer hairpin-NAT niet beschikbaar is of wanneer lokaal verkeer op het LAN moet blijven. Het werkt niet wanneer clients de bedoelde resolver omzeilen, verouderde antwoorden blijven gebruiken of het interne eindpunt een ander certificaat aanbiedt. Definieer de twee weergaven, verlaag de TTL's vóór de migratie en test naamresolutie afzonderlijk van HTTPS.

Definieer de interne en externe weergaven

Kies één FQDN voor elke applicatie. Laat deze in openbare DNS verwijzen naar de extern bereikbare proxy, tunnel of gateway; overschrijf deze in interne DNS met het privéadres van de lokale proxy.

Maak niet alleen een andere interne hostnaam om certificaatwerk te vermijden, tenzij de applicatie twee canonieke URL's ondersteunt. Eén naam houdt bladwijzers, callbacks en mobiele clients consistent bij veranderingen van locatie.

Documenteer welke subnetten de interne weergave ontvangen. Gastnetwerken hebben mogelijk het openbare antwoord nodig, terwijl vertrouwde LAN- en VPN-clients voor externe toegang het privéantwoord ontvangen via hun toegewezen resolver.

Maak de resolverselectie voorspelbaar

Adverteer de interne resolver via DHCP en via het VPN-profiel. Vraag deze eerst expliciet op en voer daarna een query uit via het besturingssysteem om een lokale cache of omzeiling van versleutelde DNS te detecteren.

Resolvercaches en verschillende DNS-bibliotheken kunnen verrassende resultaten opleveren; deze catalogus met veelvoorkomende DNS-foutscenario's legt uit waarom een wijziging bij de autoritatieve server niet onmiddellijk bij de client zichtbaar hoeft te zijn.

Wis alleen de relevante caches nadat je hebt gecontroleerd of het record bij de bron correct is. Als een beheerde browser zijn eigen versleutelde resolver gebruikt, pas dan een goedgekeurd beleid toe of accepteer het openbare pad in plaats van de lokale zone steeds opnieuw aan te passen.

Stem proxy-, certificaat- en applicatiegedrag op elkaar af

Beide eindpunten moeten een certificaat aanbieden dat geldig is voor de gedeelde FQDN en die host naar dezelfde applicatie-identiteit routeren. Een certificaatwaarschuwing betekent dat DNS een eindpunt heeft bereikt, maar dat het eindpunt niet is geconfigureerd voor de opgevraagde naam.

Controleer omleidingen, WebSockets, callback-URL's en de externe URL van de applicatie. Een lokale proxy die omleidt naar een IP-adres of een andere hostnaam ondermijnt het ontwerp met één naam.

Als de applicatie een subpad gebruikt, houd dan de basis-URL en proxyroutedienst gesynchroniseerd. De checklist van ZimaSpace voor Jellyfin-containerupgrades helpt proxy-, koppel- en URL-instellingen vóór een wijziging te behouden.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

Test overgangen tussen interne en externe toegang

Leg op wifi de DNS-server, het geretourneerde adres, het certificaat en het applicatieresultaat vast. Herhaal dit via mobiele data met uitgeschakelde wifi; het adres moet veranderen, terwijl de hostnaam en certificaatidentiteit hetzelfde blijven.

Maak vanaf een extern netwerk verbinding met de VPN en herhaal de test. Als de VPN het privépad moet gebruiken maar het openbare antwoord ontvangt, corrigeer dan de DNS-toewijzing of routering voordat je de applicatie-instellingen wijzigt.

Verplaats ten slotte een client tussen netwerken en wacht de TTL af. Stop wanneer alle drie de paden voorspelbaar zijn; draai de interne overschrijving terug als clients de verkeerde proxy bereiken of als je niet kunt bepalen welke resolver ze gebruiken.