NXDOMAIN prek VPN ne pomeni izpada tunela

Mikavno je eno neuspešno poizvedbo brati kot dokaz, da se je tunel sesul, zlasti ko je ime delovalo pred desetimi minutami. Odgovor pravi drugače. NXDOMAIN je zaključena transakcija DNS, v kateri je razreševalnik navedel, da poizvedovano ime ne obstaja; pokvarjen tunel običajno ustvari tišino, potek časa ali poskus razreševanja proti napačnemu strežniku. Različica argumenta brez wiresharka je ena poizvedba, en odgovarjajoči in ena koda odgovora, in to trojico je vredno zabeležiti pred kakršnimi koli spremembami konfiguracije.

Kaj odgovor dejansko dokazuje

DNS ločuje izide, ki jih odjemalci pogosto zlijejo v eno samo napako. Neobstoječe ime ustvari negativen odgovor s kodo NXDOMAIN, medtem ko ime, ki obstaja, a nima zapisa zahtevane vrste, ustvari uspešen odgovor s praznim razdelkom odgovorov. Oboje se aplikaciji zdi kot nič koristnega, in le eno od tega pomeni, da je ime napačno.

Ta razlika odloči, kam sodi popravilo. Manjkajoči zapis AAAA na gostitelju, ki ima zapis A, ni manjkajoči gostitelj, in ponovna izdaja potrdila ali ponovna gradnja tunela za lovljenje tega zapravi edini razpoložljivi namig. Razlika določa tudi obliko nadaljevanja: težava z imenovanjem se popravi v coni, težava z vrsto pa se popravi z zahtevo po pravilnem zapisu ali s sprejetjem, da družina naslovov preprosto manjka.

Mit: manjkajoče zasebno ime pomeni, da je tunel odpovedal

Mit preživi, ker ta dva dogodka tako pogosto prideta skupaj. Odjemalec se poveže z VPN, operacijski sistem obdrži razreševalnik, ki mu je že zaupal, in notranje ime, ki ga zdaj potrebuje, se vpraša strežnik, ki ni nikoli slišal za zasebno cono. Ta strežnik odgovori pošteno in negativno. Tunel nosi paket; odgovor se preprosto nanaša na imenski prostor, ki ga odgovarjajoči ne streže.

Postavitve split-horizon to naredijo rutinsko: isto ime cone obstaja javno in interno z različno vsebino, in zasebne zapise pozna le notranji razreševalnik. Pridobitev negativnega odgovora, ki izgleda verodostojno, je zato dokaz o tem, kateri razreševalnik je odgovoril, ne pa dokaz o stanju vmesnika.

Izid določata dve podrobnosti konfiguracije. Tunel mora potisniti ali izbrati notranji razreševalnik, in odjemalec mora to izbiro uporabiti pri iskanem imenu. Pravilo za posamezno domeno, ki poimenuje pripono nekoliko drugačno od vnesenega zapisa, bo poizvedbo poslalo po javni poti, in odgovor bo pravilen ter neuporaben.

Vprašajte pravi razreševalnik s pravim imenom

Zabeležite odgovarjajočega, preden zabeležite razsodbo. Poizvedba, ki ne pokaže, kateri strežnik je odgovoril, ne more ločiti težave s politiko od težave z imenskim prostorom, in njuna popravka nista povezana.

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

Prvi dve vrstici pokažeta, kaj je odločil lokalni razreševalnik in koga bi vprašal. Poizvedba +search ponovi, kaj naredi aplikacija, ko doda iskalno pripono, kar je pogosto prava poizvedba in ne tista, vnesena v diagnostično orodje. Zadnja vrstica vpraša notranji strežnik neposredno, z obhodom odjemalčeve politike; če to uspe, medtem ko običajna poizvedba ne uspe, je cona v redu, usmerjanje poizvedb pa ne.

Negativno predpomnjenje pojasni zamik po popravku

Negativni odgovori so po zasnovi predpomnjeni, in RFC 2308 opisuje, kako je življenjska doba negativnega predpomnilnika izpeljana iz zapisa o pooblastilu cone. Popravek zapisa ali pravila razreševalnika zato ne zagotavlja takojšnje spremembe pri odjemalcu, in ponavljanje poizvedbe, ki še vedno vrača predpomnjeni odgovor, ne dokaže nič novega. Le drug odgovarjajoči, drugo ime ali izpraznjen predpomnilnik dajo sveže dokaze.

Izpraznite lokalni predpomnilnik in nato ponovite isto poizvedbo proti istemu odgovarjajočemu. Na sistemih z lokalno storitvijo razreševalnika je to en ukaz; na drugih je to ponovni zagon storitve ali platformsko orodje, in konkretno orodje je manj pomembno kot poznejše ponovno izvajanje enakega preskusa.

Ločite ime od poti

Ko se ime razreši v pričakovani zasebni naslov, je DNS kot tema končan in naslednje vprašanje postane pot aplikacije. Gostitelj, ki odgovarja na poizvedbe, a zavrača povezavo, ima drugo težavo, in nadaljnje prilagajanje razreševalnikov po pravilnem odgovoru je način, kako incident dobi tri nepovezane spremembe. Primerjajte razrešeni naslov s tistim, na katerem storitev dejansko posluša, preden domnevate, da se ujemata.

Shranite zapis: poizvedbo, odgovarjajočega, kodo in razrešeni naslov. Ta zapis je tudi tisto, kar naredi poznejše poročilo preverljivo, in je razlika med diagnozo in zgodbo o tunelu, ki se je zdel počasen.