VPN-domenet ditt i dnsmasq er ikkje ei soneoverføring

Du leitar etter bedriftssona i dnsmasq-konfigurasjonen til klienten, finn ho ikkje og konkluderer med at VPN-en ikkje pusja domenet sitt. Det som vart pusht, er eit rutinghint, ikkje ei sone. Klienten registrerer domenet og resolvaren som skal svare for det, og den administrerte backenden gjer det om til vilkårsstyrt vidaresending. Å sjå på feil stad gjev ein sjølvsikker og heilt feil diagnose.

Det klienten godtok, er ikkje det gatewayen baud på

Ein gateway kan by på ein resolvar, eit domene og ruta som trengst for å nå den resolvaren, og klienten kan godta alle tre eller ingen av dei. Ein importert profil, eit hjelpeskript eller ein policy som ignorerer pushta alternativ, kan la det godtekne settet stå tomt medan serversida ser rett ut. Start med den registrerte tilstanden til klienten i staden for konfigurasjonen til serveren, fordi den tilstanden er det resolvaren faktisk tek imot. Manglar det godtekne domenet, spelar ingenting lenger nede noka rolle. Kontroller DNS-eigenskapane til tilkoplinga før du granskar ein cache.

Den skilnaden forklarar dei fleste rapportane om eit domene som aldri kom fram. Det vart bode på, og det vart ikkje brukt.

To slag domeineoppføringar

Ei tilkopling kan bera vanlege søkjedomene og berre-rute-domene, og den andre typen byrjar med ein tilde. Eit søkjedomene både ruter spørjingar og lèt korte namn utvidast, noko som er praktisk på ein arbeidsstasjon og overraskande på ein server. Eit berre-rute-domene seier at spørjingar for det suffikset skal gå til bestemte serverar utan å endre korleis korte namn vert løyste. Å skrive same domenet på begge måtar er ikkje redundans, fordi dei to oppføringane gjer ulike jobbar.

For eit privat namnerom er berre-rute-forma vanlegvis den du vil ha. Ho held bedriftssuffikset peika mot bedriftsresolvaren og lèt alt anna vere i fred.

localhost i resolv.conf er ikkje ein feil

Når ein lokal cacheløysar er i bruk, peikar systemfila på loopback-adressa og ingenting anna. Den oppføringa identifiserer den lokale lyttaren, ikkje oppstraumsserverane som manageren gav han. Bedriftsadressa vil med rette mangle i fila.

Å byte ut den oppføringa med ein offentleg resolvar er den klassiske feilrettinga. Ho gjenopprettar offentleg namneoppslag og kastar den vilkårsstyrte policyen i same endring.

Ikkje blande saman backendane

Ein administrert dnsmasq-instans og ein systemresolvar er ulike program med ulik konfigurasjon og ulike statusvisingar. Ein statuskommando for den eine rapporterer ingenting nyttig om den andre.

Finn ut kva backend manageren er konfigurert til å bruke, og les deretter den genererte konfigurasjonen til den backenden i staden for ei distribusjonsvid fil som tilfeldigvis finst. Managaren skriv sin eigen instanskonfigurasjon og støttar eigendefinerte alternativ for den instansen, så å redigere ei urelatert global fil endrar ingenting og ser ut som ei endring utan effekt. Å starte ein andre daemon på port 53 er verre enn unyttig, for no er to program usamde om kven som eig porten. Fastset eigaren først, og rediger deretter der eigaren les.

Test namnerommet, ikkje berre svaret

Spør etter eitt tillate privat namn og eitt offentleg kontrollnamn gjennom den vanlege vegen til applikasjonen. Ei direkte spørjing mot bedriftsserveren beviser at posten finst; ho beviser ikkje at klienten valde den serveren. Den andre spørjinga er den som testar policyen.

Gjenta deretter etter ei attkopling og etter ei fråkopling. Assosiasjonen bør følgje livssyklusen til tilkoplinga, og dei private namna bør slutte å løysast når tunnelen er borte, i staden for å falle tilbake på ein offentleg resolvar som svarar for same suffiks. Viss dei fell tilbake, har du funne ein lekkasje, som er ein annan feil enn eit øydelagt oppslag. Skriv ned kva backend som køyrde, kva domene som vart brukte, og kva kvar spørjing returnerte.