Ir vilinoši vienu neveiksmīgu vaicājumu lasīt kā pierādījumu, ka tunelis sabruka, jo īpaši tad, ja vārds darbojās pirms desmit minūtēm. Atbilde saka ko citu. NXDOMAIN ir pabeigts DNS darījums, kurā resolveris paziņoja, ka vaicātais vārds neeksistē; bojāts tunelis parasti rada klusumu, taimautu vai mēģinājumu atrisināt pret nepareizo serveri. Argumenta versija bez wireshark ir viens vaicājums, viens atbildētājs un viens atbildes kods, un šo trijnieku ir vērts fiksēt pirms jebkādām konfigurācijas izmaiņām.

Ko atbilde faktiski pierāda

DNS atdala rezultātus, ko klienti bieži sapludina vienā kļūmē. Neesošs vārds rada negatīvu atbildi ar NXDOMAIN kodu, savukārt esošs vārds, kuram nav pieprasītā tipa ieraksta, rada veiksmīgu atbildi ar tukšu atbilžu sadaļu. Abi lietotnei šķiet nekas noderīgs, un tikai viens no tiem nozīmē, ka vārds ir nepareizs.

Šī atšķirība nosaka, kur pieder labojums. Trūkstošs AAAA ieraksts resursdatorā, kuram ir A ieraksts, nav trūkstošs resursdators, un sertifikāta atkārtota izsniegšana vai tuneļa pārbūve tā vajāšanai izšķērdē vienīgo pieejamo pavedienu. Atšķirība nosaka arī turpinājuma formu: nosaukumu problēma tiek labota zonā, un tipa problēma tiek labota, pieprasot pareizo ierakstu vai pieņemot, ka adrešu saime vienkārši nav.

Mīts: trūkstošs privāts vārds nozīmē, ka tunelis nespēja

Mīts izdzīvo, jo šie divi notikumi tik bieži nāk kopā. Klients pieslēdzas VPN, operētājsistēma patur resolveri, kam tā jau uzticējās, un iekšējais vārds, kas tagad nepieciešams, tiek vaicāts serverim, kurš nekad nav dzirdējis par privāto zonu. Tas serveris atbild godīgi un noliedzoši. Tunelis pārnēsā paketi; atbilde vienkārši attiecas uz vārdu telpu, kuru atbildētājs neapkalpo.

Split-horizon izkārtojumi to padara par ikdienu: tas pats zonas vārds pastāv publiski un iekšēji ar atšķirīgu saturu, un privātos ierakstus zina tikai iekšējais resolveris. Tāpēc autoritatīvi izskatošas negatīvas atbildes iegūšana ir pierādījums par to, kurš resolveris atbildēja, nevis pierādījums par saskarnes stāvokli.

Rezultātu nosaka divas konfigurācijas detaļas. Tunelim ir jāiespiež vai jāizvēlas iekšējais resolveris, un klientam šī izvēle jāpiemēro meklētajam vārdam. Noteikums katram domēnam, kas nosauc nedaudz atšķirīgu sufiksu no ievadītā ieraksta, nosūtīs vaicājumu pa publisko ceļu, un atbilde būs pareiza un nederīga.

Jautājiet pareizajam resolverim ar pareizo vārdu

Fiksējiet atbildētāju pirms sprieduma fiksēšanas. Vaicājums, kas neparāda, kurš serveris atbildēja, nevar atšķirt politikas problēmu no vārdu telpas problēmas, un abu labojumi nav saistīti.

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

Pirmās divas rindas parāda, ko vietējais resolveris nolēma un ko tas jautātu. +search vaicājums atveido to, ko lietotne dara, pievienojot meklēšanas sufiksu, kas bieži ir īstais vaicājums, nevis tas, kas ierakstīts diagnostikas rīkā. Pēdējā rinda jautā iekšējam serverim tieši, apejot klienta politiku; ja tas izdodas, kamēr vienkāršais vaicājums neizdodas, zona ir kārtībā, bet vaicājumu maršrutēšana nav.

Negatīvā kešatmiņa izskaidro aizkavēšanos pēc labojuma

Negatīvās atbildes tiek kešotas pēc dizaina, un RFC 2308 apraksta, kā negatīvās kešatmiņas darbmūžs tiek atvasināts no zonas autoritātes ieraksta. Tāpēc ieraksta vai resolvera noteikuma labošana negarantē tūlītējas izmaiņas klientā, un vaicājuma, kas joprojām atgriež kešoto atbildi, atkārtošana nepierāda neko jaunu. Tikai cits atbildētājs, cits vārds vai iztīrīta kešatmiņa sniedz svaigus pierādījumus.

Iztīriet vietējo kešatmiņu, pēc tam atkārtojiet to pašu vaicājumu pret to pašu atbildētāju. Sistēmās, kas izmanto vietējo resolvera pakalpojumu, tā ir viena komanda; citās tas ir pakalpojuma restartēšana vai platformas utilīta, un konkrētais rīks ir mazāk svarīgs nekā pēc tam atkārtots identisks tests.

Atdaliet vārdu no ceļa

Kad vārds ir atrisināts uz gaidīto privāto adresi, DNS kā temats ir beidzies, un nākamais jautājums kļūst lietotnes ceļš. Resursdatoram, kas atbild uz vaicājumiem, bet atsaka savienojumu, ir cita problēma, un turpināt pielāgot resolverus pēc pareizas atbildes ir veids, kā incidents iegūst trīs nesaistītas izmaiņas. Salīdziniet atrisināto adresi ar to, uz kuras pakalpojums faktiski klausās, pirms pieņemat, ka abas sakrīt.

Saglabājiet ierakstu: vaicājumu, atbildētāju, kodu un atrisināto adresi. Šis ieraksts arī padara vēlāku ziņojumu pārbaudāmu, un tā ir atšķirība starp diagnozi un stāstu par tuneli, kas šķita lēns.

Saistītie raksti