Tunnelen er oppe, så hvorfor feiler det private navnet fortsatt?

Alt ved tilkoblingen ser riktig ut: tunnelen er oppe og konsollen viser det private endepunktet, men hver forespørsel feiler på navneoppslag. Det naturlige trekket er å skylde på tunnelen, som vanligvis viser seg uskyldig. Forespørselen sendes til en server som ikke vet noe om den private sonen. Ingen ruteendring vil endre det svaret, fordi problemet er hvem som ble spurt.

Hvilken resolver nådde forespørselen?

Finn resolveren som er knyttet til hver lenke, før du i det hele tatt ser på tunnelen. Linux viser servere per lenke via resolver-statuskommandoen, og macOS viser scopede resolvere i DNS-konfigurasjonsdumpen. Hvis svaret fortsatt kommer fra hjemmeruteren, ble tunnellenken aldri konsultert.

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

To faser blandes sammen her: en server som dytter en resolveradresse, og en klient som installerer den på den aktive lenken. En profil kan inneholde valget, og en logg kan vise at det kommer, mens operativsystemet fortsetter å bruke den gamle serveren. Sammenlign loggen med det lenken rapporterer, og stol på lenken.

Bruk en adresse som skynettverket faktisk svarer på

Skynettverk svarer vanligvis på private navn via en reservert adresse to plasser fra bunnen av området, så et nettverk som starter på 10.0.0.0 svarer på 10.0.0.2. Noen leverandører publiserer også en link-lokal resolver som fungerer uten å kjenne området, noe som hjelper når nettverket ble bygget av noen andre. Spør kandidatadressen direkte før du dytter den til noen. En adresse som ikke er en resolver, ser nøyaktig ut som en brannmur-drop, fordi forespørselen rett og slett aldri får svar.

Hvis den direkte forespørselen svarer innenfra nettverket, men ikke over tunnelen, er resolveren i orden og veien mellom de to punktene ikke. Det resultatet flytter undersøkelsen til ruter, videresending og tilgangsregler i stedet for klientprofilen.

En tunnel bærer ikke navnerommet

Pakker krysser; navn gjør det ikke. Hver side må få vite hvilket navnerom som tilhører den andre, og det er et eget objekt som eies av den som holder sonen. Den vanlige formen er en videresending for ett navnerom, rettet mot en resolver som er tilgjengelig over tunnelen.

I praksis trenger hver retning sin egen regel, fordi siden som eier sonen, må sende forespørselen videre. Begge retninger krever at kilden til forespørselen rutes og tillates, og den svarande siden må returnere svar gjennom tunnelen i stedet for mot internett. Hold videresendingen smal, slik at bare det private navnerommet avhenger av lenken. Å sende hver forespørsel gjennom den gjør en liten avhengighet om til et totalt utfall i det øyeblikket tunnelen faller.

Gå gjennom grensene i rekkefølge

Test resolveren som er installert på den aktive lenken, deretter en direkte forespørsel til den resolveren, deretter den samme forespørselen fra fjernsiden, og til slutt applikasjonen som bruker samme navn. Hvert trinn isolerer én grense, så en feil forteller deg hvor du skal se i stedet for å starte undersøkelsen på nytt. Et svar som virker mens applikasjonen feiler, peker på sertifikattillit eller en API-policy i stedet for DNS. Disse feilene er reelle, og ingen resolverendring vil reparere dem.

Skriv ned hvilket trinn som feilet. Den ene linjen er det neste person trenger, og det tar ti sekunder å registrere den.

Hold kjeden der neste person kan finne den

Registrer den dyttede resolveren, videresendingsregelen, den tillatte forespørselskilden og det svarande endepunktet på ett sted. Når det private navnet feiler igjen, viser oppføringen om tunnelen flyttet seg, om resolveradressen endret seg, eller om en regel ble innsnevret. Uten den starter hver hendelse på null og ender med de samme tre gjetningene.

Hold oppføringen kort nok til å forbli nøyaktig: fire linjer, en dato og navnet på den som eier hver del. En utdatert oppføring er verre enn ingen, fordi den ser autoritativ ut mens den er feil.