Je VPN-domein in dnsmasq is geen zoneoverdracht

Je zoekt de bedrijfszone in de dnsmasq-configuratie van de client, vindt die niet en concludeert dat de VPN zijn domein niet heeft gepusht. Wat werd gepusht is een routeringshint, geen zone. De client legt het domein vast en de resolver die erop moet antwoorden, en de beheerde backend maakt daar voorwaardelijke doorsturing van. Op de verkeerde plek kijken levert een zelfverzekerde en volledig onjuiste diagnose op.

Wat de client accepteerde is niet wat de gateway aanbood

Een gateway kan een resolver, een domein en de route aanbieden die nodig is om die resolver te bereiken, en de client kan alle drie of geen van alle accepteren. Een geïmporteerd profiel, een hulpscript of een beleid dat gepushte opties negeert, kan de geaccepteerde set leeg laten terwijl de serverkant er correct uitziet. Begin bij de vastgelegde staat van de client in plaats van bij de configuratie van de server, want die staat is wat de resolver werkelijk ontvangt. Ontbreekt het geaccepteerde domein, dan maakt niets verderop nog uit. Controleer de DNS-eigenschappen van de verbinding voordat je een cache onderzoekt.

Dat onderscheid verklaart de meeste meldingen van een domein dat nooit aankwam. Het werd aangeboden en het werd niet toegepast.

Twee soorten domeinvermeldingen

Een verbinding kan gewone zoekdomeinen en alleen-route-domeinen dragen, en de tweede soort begint met een tilde. Een zoekdomein routeert zowel query's als laat korte namen uitbreiden, wat handig is op een werkstation en verrassend op een server. Een alleen-route-domein zegt dat query's voor dat achtervoegsel naar specifieke servers moeten gaan zonder te veranderen hoe korte namen worden opgelost. Hetzelfde domein op beide manieren schrijven is geen redundantie, omdat de twee vermeldingen verschillend werk doen.

Voor een privé-naamruimte is de alleen-route-vorm meestal degene die je wilt. Die houdt het bedrijfsachtervoegsel naar de bedrijfsresolver wijzen en laat al het andere met rust.

localhost in resolv.conf is geen bug

Wanneer een lokale caching-resolver in gebruik is, wijst het systeembestand naar het loopbackadres en niets anders. Die vermelding identificeert de lokale listener, niet de upstreamservers die de manager eraan heeft gegeven. Het bedrijfsadres ontbreekt terecht in het bestand.

Die vermelding vervangen door een publieke resolver is de klassieke verkeerde oplossing. Het herstelt publieke naamresolutie en gooit het voorwaardelijke beleid in dezelfde bewerking weg.

Verwar de backends niet

Een beheerde dnsmasq-instantie en een systeemresolver zijn verschillende programma's met verschillende configuratie en verschillende statusweergaven. Een statuscommando voor de ene meldt niets nuttigs over de andere.

Stel vast welke backend de manager gebruikt, en lees dan de gegenereerde configuratie van die backend in plaats van een distributiebreed bestand dat toevallig bestaat. De manager schrijft zijn eigen instantieconfiguratie en ondersteunt aangepaste opties voor die instantie, dus een ongerelateerd globaal bestand bewerken verandert niets en ziet eruit als een wijziging zonder effect. Een tweede daemon op poort 53 starten is erger dan nutteloos, want nu zijn twee programma's het oneens over wie de poort bezit. Stel eerst de eigenaar vast en bewerk dan waar die eigenaar leest.

Test de naamruimte, niet alleen het antwoord

Vraag één toegestane privénaam en één publieke controlenaam op via het normale pad van de toepassing. Een directe query tegen de bedrijfsserver bewijst dat het record bestaat; het bewijst niet dat de client die server heeft gekozen. De tweede query is degene die beleid test.

Herhaal dat daarna na een herverbinding en na een verbreking. De associatie moet de levenscyclus van de verbinding volgen, en de privénamen moeten stoppen met oplossen wanneer de tunnel weg is, in plaats van terug te vallen op een publieke resolver die voor hetzelfde achtervoegsel antwoordt. Vallen ze toch terug, dan heb je een lek gevonden, wat een ander defect is dan een gebroken opzoeking. Schrijf op welke backend draaide, welke domeinen werden toegepast en wat elke query teruggaf.