Din VPN-domæne i dnsmasq er ikke en zoneoverførsel

Du leder efter den virksomhedsinterne zone i klientens dnsmasq-konfiguration, finder den ikke og konkluderer, at VPN'en ikke fik pushet sit domæne. Det, der blev pushet, er et routinghint, ikke en zone. Klienten registrerer domænet og den resolver, der skal svare på det, og den administrerede backend gør det til betinget videresendelse. At kigge det forkerte sted giver en selvsikker og helt forkert diagnose.

Det, klienten accepterede, er ikke det, gatewayen tilbød

En gateway kan tilbyde en resolver, et domæne og den rute, der skal til for at nå den resolver, og klienten kan acceptere alle tre eller ingen af dem. En importeret profil, et hjælpescript eller en politik, der ignorerer pushede indstillinger, kan efterlade det accepterede sæt tomt, mens serversiden ser korrekt ud. Start med klientens registrerede tilstand i stedet for serverens konfiguration, fordi den tilstand er det, resolveren faktisk modtager. Hvis det accepterede domæne mangler, betyder intet længere nede noget. Kontroller forbindelsens DNS-egenskaber, før du undersøger en cache.

Den sondring forklarer de fleste rapporter om et domæne, der aldrig kom frem. Det blev tilbudt, og det blev ikke anvendt.

To slags domæneindgange

En forbindelse kan bære almindelige søgedomæner og rute-kun-domæner, og den anden slags begynder med en tilde. Et søgedomæne både ruter forespørgsler og lader korte navne udvide sig, hvilket er praktisk på en arbejdsstation og overraskende på en server. Et rute-kun-domæne siger, at forespørgsler på det suffiks skal gå til bestemte servere uden at ændre, hvordan korte navne opløses. At skrive det samme domæne på begge måder er ikke redundans, fordi de to indgange gør forskellige ting.

For et privat navnerum er rute-kun-formen normalt den, du vil have. Den holder det virksomhedsinterne suffiks peget mod den virksomhedsinterne resolver og lader alt andet være.

localhost i resolv.conf er ikke en fejl

Når en lokal cacheløser bruges, peger systemfilen på loopback-adressen og intet andet. Den indgang identificerer den lokale lytter, ikke de opstrøms servere, som manageren gav den. Den virksomhedsinterne adresse vil med rette mangle i filen.

At erstatte den indgang med en offentlig resolver er den klassiske fejlrettelse. Den gendanner offentlig navneopløsning og kasserer den betingede politik i samme redigering.

Forveksl ikke backenderne

En administreret dnsmasq-instans og en systemresolver er forskellige programmer med forskellig konfiguration og forskellige statusvisninger. En statuskommando for den ene rapporterer intet nyttigt om den anden.

Find ud af, hvilken backend manageren er konfigureret til at bruge, og læs derefter den backends genererede konfiguration i stedet for en distributionsbred fil, der tilfældigvis findes. Manageren skriver sin egen instanskonfiguration og understøtter brugerdefinerede indstillinger for den instans, så at redigere en urelateret global fil ændrer intet og ser ud som en ændring uden effekt. At starte en anden daemon på port 53 er værre end ubrugeligt, for nu er to programmer uenige om, hvem der ejer porten. Fastslå ejeren først, og rediger derefter der, hvor ejeren læser.

Test navnerummet, ikke bare svaret

Forespørg på ét tilladt privat navn og ét offentligt kontrolnavn gennem applikationens normale vej. En direkte forespørgsel mod den virksomhedsinterne server beviser, at posten findes; den beviser ikke, at klienten valgte den server. Den anden forespørgsel er den, der tester politikken.

Gentag derefter efter en genopkobling og efter en afbrydelse. Associationen bør følge forbindelsens livscyklus, og de private navne bør holde op med at opløses, når tunnelen er væk, i stedet for at falde tilbage til en offentlig resolver, der svarer på samme suffiks. Hvis de falder tilbage, har du fundet en lækage, som er en anden fejl end et brudt opslag. Skriv ned, hvilken backend der kørte, hvilke domæner der blev anvendt, og hvad hver forespørgsel returnerede.