VPN-domenet ditt i dnsmasq er ikke en soneoverføring

Du leter etter bedriftssonen i klientens dnsmasq-konfigurasjon, finner den ikke og konkluderer med at VPN-en ikke pushet domenet sitt. Det som ble pushet, er et rutinghint, ikke en sone. Klienten registrerer domenet og resolveren som skal svare for det, og den administrerte backenden gjør det om til betinget videresending. Å se på feil sted gir en selvsikker og helt feil diagnose.

Det klienten aksepterte, er ikke det gatewayen tilbød

En gateway kan tilby en resolver, et domene og ruten som trengs for å nå den resolveren, og klienten kan akseptere alle tre eller ingen av dem. En importert profil, et hjelpeskript eller en policy som ignorerer pushede alternativer, kan la det aksepterte settet stå tomt mens serversiden ser riktig ut. Start med klientens registrerte tilstand i stedet for serverens konfigurasjon, fordi den tilstanden er det resolveren faktisk mottar. Mangler det aksepterte domenet, spiller ingenting lenger ned noen rolle. Kontroller tilkoblingens DNS-egenskaper før du undersøker en cache.

Den forskjellen forklarer de fleste rapportene om et domene som aldri kom frem. Det ble tilbudt, og det ble ikke brukt.

To typer domeneoppføringer

En tilkobling kan bære vanlige søkedomener og kun-rute-domener, og den andre typen begynner med en tilde. Et søkedomene både ruter spørringer og lar korte navn utvides, noe som er praktisk på en arbeidsstasjon og overraskende på en server. Et kun-rute-domene sier at spørringer for det suffikset skal gå til bestemte servere uten å endre hvordan korte navn løses. Å skrive samme domene på begge måter er ikke redundans, fordi de to oppføringene gjør forskjellige jobber.

For et privat navnerom er kun-rute-formen vanligvis den du vil ha. Den holder bedriftssuffikset pekt mot bedriftsresolveren og lar alt annet være i fred.

localhost i resolv.conf er ikke en feil

Når en lokal cacheløser er i bruk, peker systemfilen på loopback-adressen og ingenting annet. Den oppføringen identifiserer den lokale lytteren, ikke oppstrømsserverne som manageren ga den. Bedriftsadressen vil med rette mangle i filen.

Å erstatte den oppføringen med en offentlig resolver er den klassiske feilrettingen. Den gjenoppretter offentlig navneoppslag og forkaster den betingede policyen i samme endring.

Ikke forveksle backendene

En administrert dnsmasq-instans og en systemresolver er forskjellige programmer med forskjellig konfigurasjon og forskjellige statusvisninger. En statuskommando for den ene rapporterer ingenting nyttig om den andre.

Finn ut hvilken backend manageren er konfigurert til å bruke, og les deretter den backendens genererte konfigurasjon i stedet for en distribusjonsomfattende fil som tilfeldigvis finnes. Managøren skriver sin egen instanskonfigurasjon og støtter egendefinerte alternativer for den instansen, så å redigere en urelatert global fil endrer ingenting og ser ut som en endring uten effekt. Å starte en andre daemon på port 53 er verre enn ubrukelig, for nå er to programmer uenige om hvem som eier porten. Fastslå eieren først, og rediger deretter der eieren leser.

Test navnerommet, ikke bare svaret

Spør etter ett tillatt privat navn og ett offentlig kontrollnavn gjennom applikasjonens vanlige vei. En direkte spørring mot bedriftsserveren beviser at posten finnes; den beviser ikke at klienten valgte den serveren. Den andre spørringen er den som tester policyen.

Gjenta deretter etter en gjenoppkobling og etter en frakobling. Assosiasjonen bør følge tilkoblingens livssyklus, og de private navnene bør slutte å løses når tunnelen er borte, i stedet for å falle tilbake til en offentlig resolver som svarer for samme suffiks. Hvis de faller tilbake, har du funnet en lekkasje, som er en annen feil enn et ødelagt oppslag. Skriv ned hvilken backend som kjørte, hvilke domener som ble brukt, og hva hver spørring returnerte.