Tunelis ir aktīvs, tad kāpēc privātais vārds joprojām neizdodas?

Viss savienojumā izskatās pareizi: tunelis ir aktīvs un konsole rāda privāto galapunktu, tomēr katrs pieprasījums neizdodas vārdu izšķiršanā. Dabiskā rīcība ir vainot tuneli, kas parasti izrādās nevainīgs. Vaicājums tiek nosūtīts serverim, kas neko nezina par privāto zonu. Nekādas maršrutēšanas izmaiņas nemainīs šo atbildi, jo problēma ir tajā, kam jautāja.

Kuru risinātāju vaicājums sasniedza?

Atrodiet katram savienojumam piesaistīto risinātāju, pirms vispār skatāties uz tuneli. Linux rāda katra savienojuma serverus ar risinātāja statusa komandu, un macOS rāda tvēruma risinātājus DNS konfigurācijas izvadē. Ja atbilde joprojām nāk no mājas maršrutētāja, tuneļa savienojums nekad nav ticis vaicāts.

resolvectl status
scutil --dns | head -40
dig +short internal.example.com

Šeit tiek sajaukti divi posmi: serveris, kas virza risinātāja adresi, un klients, kas to instalē aktīvajā savienojumā. Profilā var būt opcija, un žurnāls var parādīt, ka tā pienāk, kamēr operētājsistēma turpina izmantot veco serveri. Salīdziniet žurnālu ar to, ko ziņo savienojums, un uzticieties savienojumam.

Izmantojiet adresi, uz kuru mākoņa tīkls patiešām atbild

Mākoņa tīkli parasti atbild uz privātiem vārdiem ar rezervētu adresi, kas atrodas divas pozīcijas no diapazona bāzes, tāpēc tīkls, kas sākas ar 10.0.0.0, atbild uz 10.0.0.2. Daži pakalpojumu sniedzēji publicē arī savienojuma lokālo risinātāju, kas darbojas, nezinot diapazonu, un tas palīdz, kad tīklu ir uzbūvējis kāds cits. Pajautājiet kandidāta adresei tieši, pirms to kādam virzāt. Adrese, kas nav risinātājs, izskatās tieši kā ugunsmūra nomešana, jo vaicājums vienkārši nekad nesaņem atbildi.

Ja tiešais vaicājums atbild no tīkla iekšpuses, bet ne caur tuneli, risinātājs ir kārtībā un ceļš starp diviem punktiem nav. Šis rezultāts pārvieto izmeklēšanu uz maršrutiem, pārsūtīšanu un piekļuves noteikumiem, nevis uz klienta profilu.

Tunelis nenes vārdu telpu

Paketes iziet cauri; vārdi ne. Katrai pusei jāpasaka, kura vārdu telpa pieder otrai, un tas ir atsevišķs objekts, kas pieder tam, kam ir zona. Parastā forma ir pārsūtīšana vienai vārdu telpai, kas vērsta uz risinātāju, kurš sasniedzams caur tuneli.

Praksē katram virzienam vajadzīgs savs noteikums, jo zona pieder pusei, kurai vaicājums jānosūta tālāk. Abiem virzieniem vajadzīgs, lai vaicājuma avots būtu maršrutēts un atļauts, un atbildošajai pusei atbildes jāatgriež caur tuneli, nevis uz internetu. Turiet pārsūtīšanu šauru, lai tikai privātā vārdu telpa būtu atkarīga no savienojuma. Ikkatra vaicājuma sūtīšana caur to mazu atkarību pārvērš pilnīgā pārtraukumā tajā brīdī, kad tunelis krīt.

Izejiet robežas pēc kārtas

Pārbaudiet aktīvajā savienojumā instalēto risinātāju, tad tiešu vaicājumu šim risinātājam, tad to pašu vaicājumu no tālās puses un visbeidzot lietojumprogrammu, kas izmanto to pašu vārdu. Katrs solis izolē vienu robežu, tāpēc kļūme parāda, kur skatīties, nevis sākt izmeklēšanu no jauna. Atbilde, kas darbojas, kamēr lietojumprogramma neizdodas, norāda uz sertifikāta uzticēšanos vai API politiku, nevis uz DNS. Šīs kļūmes ir reālas, un nekādas risinātāja izmaiņas tās nesalabos.

Pierakstiet, kurš solis neizdevās. Šī viena rinda ir tas, kas vajadzīgs nākamajam cilvēkam, un tās pierakstīšana aizņem desmit sekundes.

Turiet ķēdi tur, kur nākamais cilvēks to atradīs

Pierakstiet virzīto risinātāju, pārsūtīšanas noteikumu, atļauto vaicājuma avotu un atbildošo galapunktu vienā vietā. Kad privātais vārds atkal neizdodas, ieraksts parāda, vai tunelis pārvietojās, vai risinātāja adrese mainījās, vai noteikums tika sašaurināts. Bez tā katrs incidents sākas no nulles un beidzas ar tām pašām trim minējumiem.

Turiet ierakstu pietiekami īsu, lai tas paliktu precīzs: četras rindas, datums un tā vārds, kam pieder katra daļa. Novecojis ieraksts ir sliktāks par neesošu, jo tas izskatās autoritatīvs, kamēr ir nepareizs.