Offentlig DNS som fungerar betyder inte att Active Directory går att hitta

VPN ansluter, webbläsaren öppnar en offentlig webbplats och laptopen kan fortfarande inte logga in på domänen. Den vanliga slutsatsen är att DNS är i ordning eftersom namn löses upp. Det är det inte, och skälet är att ett webbläsartest bara prövar en uppslagning av en kedja som en domänansluten klient behöver. Domänupptäckt frågar först efter tjänsteposter, sedan efter adresserna till de kontroller som posterna namnger och till sist efter en väg till de portar som kontrollerna lyssnar på. Ett offentligt svar uppfyller ingen av dessa steg.

Myten: namn löses upp, så DNS är klart

Att en offentlig webbplats löses upp säger bara att någon resolver svarade på en A- eller AAAA-fråga för ett namn i en offentlig zon. Active Directory använder samma protokoll för en annan fråga: var finns domänens tjänster och vilken kontroller ska den här klienten använda. Frågan uttrycks som SRV-poster under en zon uppkallad efter domänen, och en rekursiv offentlig resolver har ingen anledning att hålla dem.

När posten saknas returnerar resolvern ett negativt svar, vilket är ett giltigt DNS-svar och inte ett avbrott. Klienten faller då tillbaka på cachelagrad kontrollerinformation om den har någon, och det är just därför en stationär dator kan se bra ut i timmar och misslyckas efter en omstart eller ett lösenordsbyte.

Vad en domänklient faktiskt frågar efter, i ordning

För en domän som corp.example är den generiska lokatorfrågan _ldap._tcp.dc._msdcs.corp.example. SRV-svaren namnger möjliga kontroller och deras portar, och därefter behöver klienten adressposter för dessa värdnamn innan den kan öppna en anslutning. Platsmedveten upptäckt lägger till frågor under platsens underdomän, och svaren avgör vilka kontroller som föredras, inte vilken som är obligatorisk.

nltest /dsgetdc:corp.example
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.corp.example

Följ kedjan i den ordningen, från nätverket där problemet uppstår. Ett värdnamn som löses upp till en oåtkomlig adress är ett routingfel, inte ett DNS-fel. En nåbar kontroller som saknar sina lokatorposter är ett DNS-fel, inte ett routingfel. De två ger liknande användarklagomål och helt olika reparationer.

Varför en offentlig resolver svarar och inloggningen ändå bryts

Om adaptern ger klienten en offentlig resolver fungerar offentliga namn och det interna namnområdet inte. Att lägga till en andra offentlig resolver hjälper inte, eftersom ingen av dem håller zonen. Inte heller den vanliga listan ”intern först, offentlig sedan” beter sig som en regel per domän: ett negativt svar från den första servern är ett legitimt svar, och klienten försöker inte med den andra servern igen bara för att svaret var tomt.

Båda de interna resolvrarna, om du kör två, måste hålla AD:s namnområde och vara nåbara från klientens nuvarande nätverk. Det är den här delen som split-tunnel-designer bryter: VPN:n kan bära tunnelns subnät medan den interna resolvern sitter på ett prefix som tunneln inte routar, så frågan går ut till en resolver som inte kan svara på den.

Windows tillämpar också en namnmatchningpolicy som kan styra specifika namnområden till specifika servrar, och de DNS-adresser som adaptern visar är inte hela historien. Att ändra adapterlistan utan att ändra den policyn kan lämna den effektiva konfigurationen orörd, och det är därför en rättelse som ser tillämpad ut inte har någon verkan.

Håll tunnelns DNS och dess vägar i samklang

En VPN-profil som trycker ut en resolver men inte prefixet som innehåller den skapar en resolver som klienten inte når; en som trycker ut prefixet utan resolver lämnar klienten att fråga den lokala. Behandla paret som ett konfigurationselement och kontrollera båda efter varje profiländring, eftersom ett omordnat utskick eller en ny split-tunnelpolicy kan skilja dem åt.

Kontrollera också vad klienten gör med inställningen som trycks ut. Vissa klienter tillämpar DNS-servern bara på tunnelgränssnittet och låter den fysiska adapterns resolver stå kvar, så vilken som vinner beror på gränssnittsmetriken och namnet som frågas. Om det interna svaret bara kommer när den fysiska adaptern är inaktiverad är det mekanismen som ska repareras, inte domänposterna.

Acceptera med ett upptäcktsanrop och en levande åtgärd

Ett användbart acceptanstest kör lokatorfrågan och utför sedan en riktig autentiserad åtgärd, till exempel att öppna en katalogbaserad delning eller begära en biljett. Gör det före VPN-övergången och igen efter, på samma maskin, utan omstart emellan. Cachelagrade inloggningsuppgifter och redan öppna sessioner får gärna en trasig väg att se frisk ut, så en lyckad skrivbordsinloggning är inte testet.

Microsofts rekommendationer för DNS-klienten drar samma gräns mellan att lösa upp det interna namnområdet och att vidarebefordra offentliga frågor uppåt, och det är ordningen som ska bevaras när ett VPN införs.

Om felet bara är långsamt och inte misslyckat, håll fördröjningen skild från diagnosen. En tidsgräns under upptäckten kan komma från en oåtkomlig kontroller, en blockerad port eller en resolver som svarar sent, och inget av det bevisas av väntan allena. Fånga den faktiska frågan, dess svar och anslutningsförsöket innan du ändrar en resolverinställning.