Hvorfor et privat endepunkt stadig svarer med en offentlig adresse

Bærbaren opretter forbindelse, tunnelen melder sig oppe, og lagerkontoen afviser stadig hver eneste anmodning. Det private endepunkt findes, ruten til dets undernet findes, og navnet svarer enten med en offentlig adresse eller kan ikke slås op. Der er intet i vejen med tunnelen: klienten har aldrig fået at vide, hvilken server der skal svare på det navn. Følg forespørgslen udad, og hullet bliver tydeligt.

Start ved klientens resolver

Spørg klienten, hvilken server den forespørger, mens tunnelen er oppe. En point-to-site-profil leverer den adresse, og en profil, der ikke leverer noget, overlader det til styresystemet at falde tilbage på adapterens standardindstillinger.

Offentlige resolvere har ingen indsigt i en privat zone, så de svarer fra internettet, hvilket netop er deres opgave. Den første kontrol er derfor resolver-adressen, der bruges, ikke tunnelen og ikke endepunktet.

Læs, hvad svaret egentlig er

Slå tjenestens navn op, og læs den adresse, der kommer tilbage. Et offentligt svar betyder, at forespørgslen nåede en server, der ikke kan se zonen. Intet svar betyder, at navnet kun findes privat, og at intet, klienten kan nå, holder det.

De to udfald giver lignende applikationsfejl og tilhører forskellige ejere. Det ene er et resolver-valgsproblem, det andet er et manglende zone-link.

En hosts-post beviser ruten og lyver derefter

At sætte endepunktets adresse i den lokale hosts-fil er den hurtigste måde at bevise, at tunnelen og tjenestens firewall allerede virker. Hvis anmodningen lykkes med den post, er det kun navneopslaget, der er i stykker. Det er også en ændring for hver maskine, der dækker præcis ét navn.

Den hjælper ikke den anden konto, det andet endepunkt eller en kollega, og den brækker uden varsel, når endepunktet genskabes på en ny adresse.

Værre, den får din maskine til at opføre sig anderledes end alles, og det er sådan en resolver-fejl overlever en uges undersøgelse. Brug den til at bekræfte ruten, fjern den derefter, og ret årsagen.

Knyt zonen til, og uddel en resolver

Der er to betingelser, der skal opfyldes samtidig. Den private zone skal være knyttet til det virtuelle netværk, hvor endepunktet ligger, og klienten skal sende sine forespørgsler til en server, der kan læse den zone. Et indgående endepunkt i DNS Private Resolver leverer sådan en adresse inde i netværket og besvarer forespørgsler, der ankommer via tunnelen. Sæt den adresse i VPN-profilen, og tilføj det private suffiks, klienten skal anvende.

En eksisterende resolver på stedet kan nå samme resultat via en betinget videresender rettet mod zonen.

Netværksregler på resolveren betyder lige så meget som routing. Hvis den indgående regel udelukker VPN-klienternes område, udløber forespørgslerne i stedet for at give et forkert svar. Det er den timeout, der sender folk tilbage til en rutetabel, hvor intet er galt.

Kontrollér navn, port og identitet i rækkefølge

Arbejd i rækkefølge: slå navnet op, bekræft at svaret er privat, åbn porten, og lav derefter en autentificeret anmodning. Hvert trin har sin egen ejer og sin egen fejlsignatur.

Et privat svar efterfulgt af en timeout peger på en rute eller en firewall. Et offentligt svar peger på resolveren. En fuldført forbindelse, der returnerer en identitetsfejl, tilhører tjenesten.

Endnu en fejl hører på denne liste. En tjenestefirewall, der tillader en klientadresse, holder op med at matche, når puljen giver adressen til en anden session efter en genopkobling. Læs den kaldende adresse, tjenesten har registreret, i stedet for den, klienten tror, den har. De to er uenige oftere, end folk forventer. Azure DNS Private Resolver-vejledningen dækker zone-linket og videresendelsesopsætningen.