Tunelis veikia, tai kodėl privatus vardas vis tiek nepavyksta?

Viskas ryšyje atrodo teisingai: tunelis veikia ir konsolė rodo privatų galinį tašką, tačiau kiekviena užklausa nepavyksta sprendžiant vardus. Natūralus žingsnis yra kaltinti tunelį, kuris paprastai pasirodo nekaltas. Užklausa siunčiama serveriui, kuris nieko nežino apie privačią zoną. Joks maršrutizavimo pakeitimas to atsakymo nepakeis, nes problema yra tai, ko buvo paklausta.

Kurį resolverį pasiekė užklausa?

Raskite prie kiekvienos jungties prijungtą resolverį prieš apskritai žiūrėdami į tunelį. Linux rodo kiekvienos jungties serverius resolverio būsenos komanda, o macOS rodo apimties resolverius DNS konfigūracijos išvestyje. Jei atsakymas vis dar ateina iš namų maršrutizatoriaus, tunelio jungtis niekada nebuvo konsultuota.

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

Čia sumaišomi du etapai: serveris, stumiantis resolverio adresą, ir klientas, įdiegiantis jį aktyvioje jungtyje. Profilis gali turėti parinktį, o žurnalas gali rodyti, kad ji ateina, tuo tarpu operacinė sistema toliau naudoja seną serverį. Palyginkite žurnalą su tuo, ką praneša jungtis, ir pasitikėkite jungtimi.

Naudokite adresą, į kurį debesijos tinklas tikrai atsako

Debesijos tinklai paprastai atsako į privačius vardus per rezervuotą adresą, esantį dviem pozicijomis nuo diapazono bazės, todėl tinklas, prasidedantis 10.0.0.0, atsako 10.0.0.2. Kai kurie tiekėjai taip pat skelbia jungties vietinį resolverį, kuris veikia nežinant diapazono, o tai padeda, kai tinklą pastatė kas nors kitas. Paklauskite kandidato adreso tiesiogiai prieš jį kam nors stumdami. Adresas, kuris nėra resolveris, atrodo lygiai kaip ugniasienės numetimas, nes užklausa tiesiog niekada negauna atsakymo.

Jei tiesioginė užklausa atsako iš tinklo vidaus, bet ne per tunelį, resolveris tvarkingas, o kelias tarp dviejų taškų ne. Šis rezultatas perkelia tyrimą į maršrutus, persiuntimą ir prieigos taisykles, o ne į kliento profilį.

Tunelis neneša vardų erdvės

Paketai praeina; vardai ne. Kiekvienai pusei reikia pasakyti, kuri vardų erdvė priklauso kitai, ir tai yra atskiras objektas, kurį valdo tas, kas turi zoną. Įprasta forma yra persiuntimas vienai vardų erdvei, nukreiptas į resolverį, pasiekiamą per tunelį.

Praktiškai kiekviena kryptis turi savo taisyklę, nes zoną valdanti pusė turi siųsti užklausą toliau. Abi kryptys reikalauja, kad užklausos šaltinis būtų maršrutizuotas ir leidžiamas, o atsakanti pusė turi grąžinti atsakymus per tunelį, o ne į internetą. Laikykite persiuntimą siaurą, kad tik privati vardų erdvė priklausytų nuo jungties. Siųsti kiekvieną užklausą per jį mažą priklausomybę paverčia visišku sutrikimu tą akimirką, kai tunelis krenta.

Pereikite ribas iš eilės

Išbandykite aktyvioje jungtyje įdiegtą resolverį, tada tiesioginę užklausą tam resolveriui, tada tą pačią užklausą iš tolimos pusės ir galiausiai programą, naudojančią tą patį vardą. Kiekvienas žingsnis izoliuoja vieną ribą, todėl gedimas pasako, kur žiūrėti, o ne pradėti tyrimą iš naujo. Atsakymas, kuris veikia, kai programa nepavyksta, rodo sertifikato pasitikėjimą arba API politiką, o ne DNS. Tie gedimai yra tikri, ir joks resolverio pakeitimas jų nepataisys.

Užsirašykite, kuris žingsnis nepavyko. Ta viena eilutė yra tai, ko reikia kitam žmogui, ir ją užrašyti trunka dešimt sekundžių.

Laikykite grandinę ten, kur kitas žmogus ją ras

Užrašykite stumtą resolverį, persiuntimo taisyklę, leidžiamą užklausos šaltinį ir atsakantį galinį tašką vienoje vietoje. Kai privatus vardas vėl nepavyksta, įrašas parodo, ar tunelis pajudėjo, ar pasikeitė resolverio adresas, ar taisyklė buvo susiaurinta. Be jo kiekvienas incidentas prasideda nuo nulio ir baigiasi tomis pačiomis trimis prielaidomis.

Laikykite įrašą pakankamai trumpą, kad jis liktų tikslus: keturios eilutės, data ir kiekvienos dalies savininko vardas. Pasenęs įrašas yra blogesnis už jokį, nes jis atrodo autoritetingas, nors yra neteisingas.