Hvorfor et privat endepunkt fortsatt svarer med en offentlig adresse
Følg spørringen fra bærbaren og utover: hvilken resolver som svarer, hvilken adresse som kommer tilbake, og hva som må kobles til før et privat endepunkt er tilgjengelig.
Bærbaren kobler til, tunnelen melder seg oppe, og lagringskontoen avviser fortsatt hver eneste forespørsel. Det private endepunktet finnes, ruten til undernettet finnes, og navnet svarer enten med en offentlig adresse eller lar seg ikke slå opp. Ingenting er galt med tunnelen: klienten har aldri fått vite hvilken server som skal svare for det navnet. Følg spørringen utover, og gapet blir tydelig.
Start ved klientens resolver
Spør klienten hvilken server den spør mens tunnelen er oppe. En punkt-til-område-profil leverer den adressen, og en profil som ikke leverer noe, lar operativsystemet falle tilbake på adapterens standardverdier.
Offentlige resolvere har ingen oversikt over en privat sone, så de svarer fra internett, som er nøyaktig jobben deres. Den første kontrollen er derfor resolveradressen som brukes, ikke tunnelen og ikke endepunktet.
Les hva svaret egentlig er
Slå opp tjenestenavnet og les adressen som kommer tilbake. Et offentlig svar betyr at spørringen nådde en server som ikke kan se sonen. Intet svar betyr at navnet bare finnes privat og at ingenting klienten kan nå holder på det.
Disse to utfallene gir lignende applikasjonsfeil og tilhører forskjellige eiere. Det ene er et resolver-valgproblem, det andre er en manglende sonekobling.
En hosts-oppføring beviser ruten og lyver deretter
Å sette endepunktets adresse i den lokale hosts-filen er den raskeste måten å bevise at tunnelen og tjenestens brannmur allerede virker. Hvis forespørselen lykkes med den oppføringen, er bare navneoppslaget ødelagt. Det er også en endring per maskin som dekker nøyaktig ett navn.
Den hjelper ikke den andre kontoen, det andre endepunktet eller en kollega, og den ryker uten varsel når endepunktet gjenskapes på en ny adresse.
Verre, den får maskinen din til å oppføre seg annerledes enn alles, og det er slik en resolverfeil overlever en uke med undersøkelser. Bruk den til å bekrefte ruten, fjern den deretter og rett opp årsaken.
Koble til sonen og del ut en resolver
To betingelser må gjelde samtidig. Den private sonen må være koblet til det virtuelle nettverket der endepunktet ligger, og klienten må sende spørringene sine til en server som kan lese den sonen. Et inngående endepunkt i DNS Private Resolver gir en slik adresse inne i nettverket og svarer på spørringer som kommer gjennom tunnelen. Sett den adressen i VPN-profilen og legg til det private suffikset klienten skal bruke.
En eksisterende lokal resolver kan nå samme resultat via en betinget videresender rettet mot sonen.
Nettverksregler på resolveren betyr like mye som ruting. Hvis den inngående regelen utelukker VPN-klientenes område, utløper spørringene i stedet for å gi et galt svar. Det er den utløpstiden som sender folk tilbake til en rutetabell der ingenting er galt.
Kontroller navn, port og identitet i rekkefølge
Arbeid i rekkefølge: slå opp navnet, bekreft at svaret er privat, åpne porten, og gjør deretter en autentisert forespørsel. Hvert trinn har sin egen eier og sin egen feilsignatur.
Et privat svar etterfulgt av en utløpstid peker på en rute eller en brannmur. Et offentlig svar peker på resolveren. En fullført tilkobling som returnerer en identitetsfeil, tilhører tjenesten.
Nok en feil hører hjemme på denne listen. En tjenestebrannmur som tillater en klientadresse slutter å stemme når bassenget gir den adressen til en annen økt etter en gjentilkobling. Les anroperadressen tjenesten registrerte, ikke den klienten tror den har. De to er uenige oftere enn folk forventer. Veiledningen for Azure DNS Private Resolver dekker sonekoblingen og videresenderoppsettet.