Fjärrskrivbord via ett VPN: i vilket fel är du?

Din tunnel är uppe, den interna wikin laddas och Fjärrskrivbord vägrar fortfarande ansluta. Den kombinationen är normal, eftersom VPN ger en rutt till värden medan skrivbordstjänsten måste lyssna, tillåtas av sin egen brandvägg och vara villig att autentisera kontot. Fyra felstadier ligger mellan en fungerande tunnel och en användbar session, och varje stadium misslyckas med ett annat meddelande. Läs meddelandet först, eftersom det namnger stadiet.

Fyra fel som ser ut som ett

Stadierna är ordnade: namnet slås upp till den privata adress som designen avser, porten svarar på en TCP-handskakning, värden accepterar anslutningen enligt sin egen policy och sessionsinloggningen lyckas. Varje stadium gör nästa omöjligt att testa, och därför skapar ändringar av RDP-inställningar innan nätverket är utrett bara brus. Symtomet ser identiskt ut från användarens sida i alla fyra fallen. Bara klientens meddelande skiljer dem.

En fungerande intern webbplats bevisar ingen av de fyra. Den bevisar att en värd på samma nätverk svarade på en annan port med en annan tjänst. Behandla det som bevis om routning och inget mer.

Testa i ordning och skriv ner resultatet. Att hoppa till inloggningsskärmen eftersom porten svarade är sättet att lägga en eftermiddag på ett brandväggsproblem som första steget redan har lokaliserat.

Lyssnar något på 3389?

Börja med namnet, eftersom ett namn som slås upp till fel adress ogiltigförklarar varje senare test. Fråga tunnelns uppslagningstjänst vad namnet betyder och jämför sedan svaret med den privata adress som designen avser, inte med ett lyckat svar. Ett namn som slås upp till en offentlig adress är hela problemet, och ingen RDP-ändring rättar det:

nslookup desktop.corp.example
Resolve-DnsName desktop.corp.example

Testa därefter porten i stället för värden. En slutförd TCP-handskakning på 3389 skiljer nåbarhet från allt som ligger ovanför:

Test-NetConnection -ComputerName desktop.corp.example -Port 3389

Kör det testet från LAN och från tunneln, eftersom en skillnad mellan de två resultaten lokaliserar felet till VPN-rutten. Två brandväggar ligger på rutten och de är lätta att förväxla: nätverket måste tillåta klientens tunneladress att nå värden, och värdens egen brandvägg måste tillåta samma källa på den lyssnande porten. En regel begränsad till LAN-subnätet täcker inte VPN-klientpoolen, och det är den vanligaste orsaken till en timeout som bara fjärranvändare rapporterar. Kontrollera regelns omfattning, inte om den finns.

Returvägen förtjänar samma kontroll. Svar behöver en rutt tillbaka till klientpoolen i stället för till LAN, och en översättning framför värden ändrar den källa som din logg visar. Om porten svarar åt ena hållet och inte åt det andra är den saknade halvan vanligtvis returvägen.

Läs meddelandet innan du läser konfigurationen

Det tredje stadiet är värden som avvisar anslutningen enligt sin egen policy, vilket ofta ser ut som en port som öppnas och stängs direkt. Något svarade, och det är användbar information i stället för tystnad. Om handskakningen slutfördes och sessionen dog direkt är nätverket i ordning och värden bestämmer. Titta på behörigheterna för Fjärrskrivbord innan du rör nätverket igen.

Funktionen kan vara aktiverad för datorn medan åtkomsten är begränsad till vissa grupper, och lyssnaren kan vara bunden på sätt som utesluter adressen du kom från. Nätverksnivåautentisering lägger till en port som misslyckas innan skrivbordet laddas, och dess feltext skiljer sig från ett felaktigt lösenord. Jämför klientens meddelande med värdens händelselogg, eftersom meddelandet namnger porten och loggen namnger kontot.

Sessionsinloggning är sin egen gräns

Autentisering tillhör skrivbordstjänsten, inte VPN. Tunnelnns identitet och skrivbordskontot är separata uppgifter med separata låsningsprinciper, så en fungerande tunnel bevisar bara att tunneln accepterade dig. Låsning av skrivbordskontot stör inte tunneln, och det omvända är också sant.

Håll båda intakta. När den privata rutten saknas, reparera rutten, eftersom publicering av lyssnaren på internet byter ett nåbarhetsfel mot ett exponerat skrivbord. Försvaga inte heller sessionens identitetskontroller för att komma förbi en certifikatvarning som dök upp samtidigt. Ett självsignerat certifikat på en RDP-lyssnare ger en varning enligt design, så att acceptera det är ett beslut och inte ett steg.

Räkna försöken innan du försöker igen. Låströsklarna för skrivbordet räknar misslyckade inloggningar separat från VPN-fel, och en klient som försöker igen på en timer kan passera tröskeln medan du fortfarande redigerar en regel. Det är samma parallella återförsöksmekanism som låser konton efter ett lösenordsbyte.

Vad sessionen kan flytta, och var det stannar

Lär dig det godkända utloggningsflödet innan du behöver det. Att stänga fönstret kan bara koppla från vyn medan sessionen fortsätter under sin konfigurerade policy, vilket spelar roll på en delad eller granskad värd. Logga ut inifrån sessionen när policyn förväntar det.

Bestäm sedan vad sessionen får bära, eftersom urklipp, omdirigerade enheter, skrivaromdirigering och filöverföring flyttar data mellan de lokala och fjärranslutna systemen där policyn tillåter det. Ett publicerat program som körs på andra sidan är inte automatiskt en gräns utan nedladdning, och en session som ser skrivskyddad ut kan ändå bära ett urklipp. Testa den verkliga uppgiften i stället för anslutningen: öppna filen, använd programmet och bekräfta den omdirigering du behöver. Microsofts vägledning för att nå ett fjärrskrivbord utifrån beskriver de exponeringsalternativ som stöds, och den är en bättre referens än en offentlig lyssnare som lagts till under press.