Tunnel on üleval, miks privaatne nimi siiski ei toimi?

Ühenduse juures näib kõik õige: tunnel on üleval ja konsool näitab privaatset lõpp-punkti, kuid iga päring ebaõnnestub nimede lahendamisel. Loomulik käik on süüdistada tunnelit, mis osutub tavaliselt süütuks. Päring saadetakse serverile, mis ei tea privaatsest tsoonist midagi. Ükski marsruudimuudatus ei muuda seda vastust, sest probleem on selles, kelle käest küsiti.

Millise resolverini päring jõudis?

Leidke igale lingile kinnitatud resolver enne, kui tunnelile üldse vaatate. Linux näitab lülipõhiseid servereid resolveri oleku käsuga ja macOS näitab ulatusega resolvereid oma DNS-konfiguratsiooni väljundis. Kui vastus tuleb endiselt koduruuterist, ei ole tunneli linki kunagi küsitud.

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

Siin aetakse segi kaks etappi: server, mis lükkab resolveri aadressi, ja klient, mis paigaldab selle aktiivsele lingile. Profiil võib valikut sisaldada ja logi võib näidata selle saabumist, samal ajal kui operatsioonisüsteem jätkab vana serveri kasutamist. Võrrelge logi sellega, mida link teatab, ja usaldage linki.

Kasutage aadressi, millele pilvevõrk tõesti vastab

Pilvevõrgud vastavad privaatsetele nimedele tavaliselt reserveeritud aadressi kaudu, mis on vahemiku baasist kaks kohta eemal, seega 10.0.0.0-st algav võrk vastab aadressil 10.0.0.2. Mõned pakkujad avaldavad ka lingilokaalse resolveri, mis töötab vahemikku teadmata, mis aitab siis, kui võrgu on ehitanud keegi teine. Küsige kandidaat-aadressi otse, enne kui selle kellelegi lükkate. Aadress, mis ei ole resolver, näeb välja täpselt nagu tulemüüri drop, sest päring ei saa lihtsalt kunagi vastust.

Kui otsene päring vastab võrgu seest, kuid mitte läbi tunneli, on resolver korras ja kahe punkti vaheline tee mitte. See tulemus viib uurimise marsruutide, edastamise ja juurdepääsureeglite juurde, mitte kliendi profiili juurde.

Tunnel ei kanna nimeruumi

Paketid lähevad läbi; nimed mitte. Kummagi poole jaoks tuleb öelda, milline nimeruum kuulub teisele, ja see on eraldi objekt, mida valdab see, kelle käes tsoon on. Tavaline vorm on ühe nimeruumi edastamine, mis on suunatud tunnelist kättesaadavale resolverile.

Praktikas vajab kumbki suund oma reeglit, sest tsooni omav pool peab päringu edasi saatma. Mõlemad suunad vajavad, et päringu allikas oleks marsruuditud ja lubatud, ning vastav pool peab vastused tagastama läbi tunneli, mitte internetti. Hoidke edastus kitsas, nii et lingist sõltub ainult privaatne nimeruum. Iga päringu sealt läbi saatmine muudab väikese sõltuvuse täielikuks katkestuseks hetkel, mil tunnel langeb.

Käige piirid järjest läbi

Testige aktiivsele lingile paigaldatud resolverit, seejärel otsest päringut sellele resolverile, seejärel sama päringut kaugemalt poolelt ja lõpuks rakendust, mis kasutab sama nime. Iga samm isoleerib ühe piiri, nii et tõrge ütleb, kuhu vaadata, selle asemel et uurimist uuesti alustada. Vastus, mis töötab, samal ajal kui rakendus ei tööta, viitab sertifikaadi usaldusele või API-poliitikale, mitte DNS-ile. Need tõrked on tõelised ja ükski resolveri muudatus ei paranda neid.

Kirjutage üles, milline samm ebaõnnestus. See üks rida on see, mida järgmine inimene vajab, ja selle kirjapanek võtab kümme sekundit.

Hoidke ahelat seal, kust järgmine inimene selle leiab

Kirjutage lükatud resolver, edastusreegel, lubatud päringuallikas ja vastav lõpp-punkt ühte kohta. Kui privaatne nimi taas ebaõnnestub, näitab kirje, kas tunnel liikus, resolveri aadress muutus või reeglit kitsendati. Ilma selleta algab iga juhtum nullist ja lõpeb samade kolme oletusega.

Hoidke kirje piisavalt lühike, et see püsiks täpne: neli rida, kuupäev ja iga osa omaniku nimi. Aegunud kirje on hullem kui puuduv, sest see näeb autoriteetne välja, olles vale.