Tunnelen er oppe, så kvifor feilar det private namnet framleis?

Alt ved tilkoplinga ser rett ut: tunnelen er oppe og konsollen viser det private endepunktet, men kvar førespurnad feilar på namneoppslag. Det naturlege trekket er å skylde på tunnelen, som vanlegvis viser seg uskuldig. Førespurnaden blir send til ein tenar som ikkje veit noko om den private sona. Inga ruteendring vil endre det svaret, fordi problemet er kven som vart spurd.

Kva oppløysar nådde førespurnaden?

Finn oppløysaren som er knytt til kvar lenkje, før du i det heile ser på tunnelen. Linux viser tenarar per lenkje via oppløysar-statuskommandoen, og macOS viser oppløysarar med omfang i DNS-konfigurasjonsdumpen. Viss svaret framleis kjem frå heimerutaren, vart tunnellenkja aldri konsultert.

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

Her blir to fasar blanda saman: ein tenar som dyttar ei oppløysaradresse, og ein klient som installerer ho på den aktive lenkja. Ein profil kan innehalde valet, og ein logg kan vise at det kjem, medan operativsystemet held fram med å bruke den gamle tenaren. Samanlikn loggen med det lenkja rapporterer, og stol på lenkja.

Bruk ei adresse som skynettverket faktisk svarar på

Skynettverk svarar vanlegvis på private namn via ei reservert adresse to plassar frå botnen av området, så eit nettverk som startar på 10.0.0.0 svarar på 10.0.0.2. Nokre leverandørar publiserer også ein link-lokal oppløysar som fungerer utan å kjenne området, noko som hjelper når nokon andre bygde nettverket. Spør kandidatadressa direkte før du dyttar ho til nokon. Ei adresse som ikkje er ein oppløysar, ser nøyaktig ut som ein brannmur-drop, fordi førespurnaden rett og slett aldri får svar.

Viss den direkte førespurnaden svarar innanfrå nettverket, men ikkje over tunnelen, er oppløysaren i orden og vegen mellom dei to punkta ikkje. Det resultatet flyttar undersøkinga til ruter, videresending og tilgangsreglar i staden for klientprofilen.

Ein tunnel ber ikkje namnerommet

Pakkar kryssar; namn gjer det ikkje. Kvar side må få vite kva namnerom som høyrer til den andre, og det er eit eige objekt som blir eigd av den som held sona. Den vanlege forma er ei videresending for eitt namnerom, retta mot ein oppløysar som er tilgjengeleg over tunnelen.

I praksis treng kvar retning si eiga regel, fordi sida som eig sona, må sende førespurnaden vidare. Begge retningane krev at kjelda til førespurnaden blir ruta og tillaten, og den svarande sida må returnere svar gjennom tunnelen i staden for mot internett. Hald videresendinga smal, slik at berre det private namnerommet er avhengig av lenkja. Å sende kvar førespurnad gjennom ho gjer ei lita avhengigheit om til eit totalt utfall i det augeblikket tunnelen fell.

Gå gjennom grensene i rekkjefølgje

Test oppløysaren som er installert på den aktive lenkja, deretter ein direkte førespurnad til den oppløysaren, deretter den same førespurnaden frå fjerdsida, og til slutt applikasjonen som brukar same namn. Kvart steg isolerer éi grense, så ein feil fortel deg kvar du skal sjå i staden for å starte undersøkinga på nytt. Eit svar som verkar medan applikasjonen feilar, peikar på sertifikattillit eller ein API-policy i staden for DNS. Dei feila er reelle, og inga oppløysar-endring vil reparere dei.

Skriv ned kva steg som feila. Den eine linja er det neste person treng, og det tek ti sekund å registrere ho.

Hald kjeda der neste person kan finne ho

Registrer den dytta oppløysaren, videresendingsregelen, den tillatne førespurnadskjelda og det svarande endepunktet på eitt stad. Når det private namnet feilar igjen, viser oppføringa om tunnelen flytta seg, om oppløysaradressa endra seg, eller om ein regel vart innsnevra. Utan ho startar kvar hending på null og endar med dei same tre gjettingane.

Hald oppføringa kort nok til å halde seg nøyaktig: fire linjer, ein dato og namnet på den som eig kvar del. Ei utdatert oppføring er verre enn inga, fordi ho ser autoritativ ut medan ho er feil.