Varför en privat slutpunkt fortfarande svarar med en offentlig adress

Den bärbara datorn ansluter, tunneln rapporterar sig uppe, och lagringskontot avvisar fortfarande varje begäran. Den privata slutpunkten finns, vägen till dess undernät finns, och namnet svarar antingen med en offentlig adress eller går inte att slå upp. Inget är fel på tunneln: klienten har aldrig fått veta vilken server som ska svara för det namnet. Följ frågan utåt och gapet blir uppenbart.

Börja vid klientens resolver

Fråga klienten vilken server den frågar medan tunneln är uppe. En punkt-till-plats-profil levererar den adressen, och en profil som inte levererar något låter operativsystemet falla tillbaka på adapterns standardvärden.

Offentliga resolvers har ingen insyn i en privat zon, så de svarar från internet, vilket är precis deras uppgift. Det första steget är därför resolveradressen som används, inte tunneln och inte slutpunkten.

Läs vad svaret egentligen är

Lös upp tjänstens namn och läs adressen som kommer tillbaka. Ett offentligt svar betyder att frågan nådde en server som inte kan se zonen. Inget svar betyder att namnet bara finns privat och att inget som klienten kan nå håller det.

De två utfallen ger liknande applikationsfel och tillhör olika ägare. Det ena är ett resolvervalsproblem, det andra är en saknad zonkoppling.

En hosts-post bevisar vägen och ljuger sedan

Att sätta slutpunktens adress i den lokala hosts-filen är det snabbaste sättet att bevisa att tunneln och tjänstens brandvägg redan fungerar. Om begäran lyckas med den posten är det bara namnmatchningen som är trasig. Det är också en ändring per maskin som täcker exakt ett namn.

Den hjälper inte det andra kontot, den andra slutpunkten eller en kollega, och den går sönder utan varning när slutpunkten återskapas på en ny adress.

Värre, den får din maskin att bete sig annorlunda än allas, och det är så ett resolverfel överlever en veckas utredning. Använd den för att bekräfta vägen, ta sedan bort den och åtgärda orsaken.

Koppla zonen och dela ut en resolver

Två villkor måste gälla samtidigt. Den privata zonen måste vara kopplad till det virtuella nätverk där slutpunkten finns, och klienten måste skicka sina frågor till en server som kan läsa den zonen. En inkommande slutpunkt i DNS Private Resolver ger en sådan adress inne i nätverket och svarar på frågor som kommer genom tunneln. Sätt den adressen i VPN-profilen och lägg till det privata suffix som klienten ska använda.

En redan befintlig lokal resolver kan nå samma resultat via en villkorad vidarebefordrare riktad mot zonen.

Nätverksregler på resolvern betyder lika mycket som routning. Om den inkommande regeln utesluter VPN-klienternas intervall tar frågorna timeout i stället för att ge ett felaktigt svar. Det är den timeouten som skickar folk tillbaka till en routingtabell där inget är fel.

Kontrollera namn, port och identitet i ordning

Arbeta i ordning: lös upp namnet, bekräfta att svaret är privat, öppna porten och gör sedan en autentiserad begäran. Varje steg har sin egen ägare och sin egen felsignatur.

Ett privat svar följt av en timeout pekar på en väg eller en brandvägg. Ett offentligt svar pekar på resolvern. En slutförd anslutning som returnerar ett identitetsfel tillhör tjänsten.

Ytterligare ett fel hör hemma på den här listan. En tjänstebrandvägg som tillåter en klientadress slutar stämma när poolen ger den adressen till en annan session efter återanslutning. Läs anroparens adress som tjänsten registrerade, inte den som klienten tror sig ha. De två är oeniga oftare än folk väntar sig. Vägledningen för Azure DNS Private Resolver täcker zonkopplingen och vidarebefordringsarrangemanget.