Privé-DNS-naam of gewoon een IP? Beslis voordat je het deelt

Kies de naam op basis van het resolverpad en de toegangsregel op basis van de bron die de dienst ziet. Dat zijn twee aparte beslissingen, en elk heeft zijn eigen test.

Twee vragen raken door elkaar wanneer een privédienst wordt geopend voor externe gebruikers. De eerste is welke naam clients moeten gebruiken; de tweede is welke bronnen de dienst moet toelaten. Beantwoord ze in die volgorde, want een juiste naam achter de verkeerde toegangsregel faalt nog steeds, en een juiste regel achter een naam die niet wordt opgelost, wordt nooit getest.

Eerste voorwaarde: welk resolverpad hebben clients?

Een privénaam werkt alleen als de resolver van de client hem kan beantwoorden. Dat betekent dat een geautoriseerde externe client een DNS-server moet bereiken die de zone bevat, hetzij via de tunnel, hetzij via een resolver die de organisatie al voor externe gebruikers draait. De tunnel is een transport, geen gids. Hij geeft de client een pad naar een resolver, en hij vertelt de client niet welke zone hij moet opvragen.

resolvectl query files.corp.example
dig @10.20.30.10 +short files.corp.example

Een openbare resolver leert geen privézone omdat de laptop met een VPN is verbonden.

Het achtervoegsel verdient dezelfde aandacht. Gebruik een subdomein van een domein dat de organisatie beheert, zodat eigendom en certificaatplanning expliciet blijven. Vermijd .local: de specificatie voor multicast DNS bindt dat achtervoegsel aan link-local-resolutie, en een gerouteerde tunnel reproduceert dat gedrag niet voor je.

Tweede voorwaarde: welke bron ontvangt de dienst?

Toegangsregels worden tegen adressen geschreven, dus de nuttige vraag is welk adres de dienst ziet na routering en vertaling. Voor een voorbeelddienst op 10.20.30.40 komen kantoorclients uit 10.20.30.0/24 en externe clients uit een aparte pool zoals 10.99.0.0/24.

Als een gateway de externe pool vertaalt, ziet de dienst de vertaler, en een regel die voor 10.99.0.0/24 is geschreven, zal niet kloppen.

Lees dit van de kant van de dienst in plaats van de kant van de client. Een luisterlog of een packet capture op de diensthost toont de bron die werkelijk aankwam; het eigen adres van de client is slechts een gok over wat het pad heeft overleefd.

Derde voorwaarde: is de naam aan een dienst of aan een host gekoppeld?

Een naam die naar het adres van één machine wijst, koppelt elke client aan die machine. Een naam die naar een load balancer of een stabiel dienstadres wijst, overleeft vervanging van de host erachter. Kies bewust, want dit later wijzigen betekent de bladwijzers van elke client en het onderwerp van elk certificaat wijzigen.

Voor één interne dienst is een direct record meestal prima en eenvoudiger te doordenken.

Voor alles wat vervangen, herbouwd of geschaald wordt, is een stabiele front end de extra configuratie waard. De test is eenvoudig: als je de backend kunt vervangen zonder het gebruikers te vertellen, is de naam aan de dienst gekoppeld; als dat niet kan, is hij aan een host gekoppeld.

Test de twee beslissingen afzonderlijk

Los eerst op, verbind dan. Een resolutietest die het verwachte adres teruggeeft, bewijst het naampad en zegt niets over toegang. Een verbindingstest bewijst het pad en de regel samen, dus voer hem pas uit nadat de resolutie is geslaagd.

curl -sv --max-time 5 https://files.corp.example/health

Test daarna één keer een verboden bron, en noteer het resultaat.

Houd de twee records gescheiden in je documentatie: de naam en zijn zone, de toegelaten bronnen en de eigenaar van de regel. Wanneer het ene verandert, hoeft het andere niet.

Waar de beslissing meestal misgaat

De gebruikelijke fout is een dienst die wordt gepubliceerd onder een naam die alleen op het kantoor netwerk wordt opgelost, met een toegangsregel die alleen het kantoorbereik toelaat. Externe gebruikers melden dan een kapotte dienst die in werkelijkheid twee aparte weglatingen is. De tweede gebruikelijke fout is het omgekeerde: een brede toegangsregel die is toegevoegd om een naamprobleem weg te nemen, laat de dienst bereikbaar vanaf bronnen die niemand bedoelde. Beide zijn configuratieweglatingen, en vanaf de stoel van de gebruiker zien ze er hetzelfde uit.

Geen van de fouten is zichtbaar vanuit één geslaagde test. Daarom verdienen de twee beslissingen aparte records en aparte tests, zelfs wanneer dezelfde persoon ze beide neemt.

Schrijf beide op voordat de dienst live gaat, want de volgende wijziging is makkelijker te doordenken. Het record is kort: één regel voor de naam en zijn zone, één regel voor de toegelaten bronnen en de eigenaar van de regel.

Gerelateerde artikelen