Fjernskrivebord gennem en VPN: hvilken fejl er du i?

Din tunnel er oppe, den interne wiki indlæses, og Fjernskrivebord nægter stadig at forbinde. Den kombination er normal, fordi VPN giver en rute til værten, mens skrivebordstjenesten skal lytte, være tilladt af sin egen firewall og være villig til at godkende kontoen. Fire fejlstadier ligger mellem en fungerende tunnel og en brugbar session, og hvert af dem fejler med en anden meddelelse. Læs meddelelsen først, da den navngiver stadiet.

Fire fejl, der ligner én

Stadierne er ordnet: navnet opløses til den private adresse, som designet tilsigter, porten svarer på et TCP-håndtryk, værten accepterer forbindelsen efter sin egen politik, og sessionslogin lykkes. Hvert stadie gør det næste umuligt at teste, og derfor skaber ændringer af RDP-indstillinger, før netværket er afklaret, kun støj. Symptomet ser identisk ud fra brugerens side i alle fire tilfælde. Kun klientens meddelelse adskiller dem.

Et fungerende internt websted beviser ingen af de fire. Det beviser, at en vært på samme netværk svarede på en anden port med en anden tjeneste. Betragt det som bevis om routing og intet andet.

Test i rækkefølge, og skriv resultatet ned. At springe til login-skærmen, fordi porten svarede, er måden, hvorpå en eftermiddag går med et firewall-problem, som det første trin allerede har lokaliseret.

Lytter der noget på 3389?

Begynd med navnet, fordi et navn, der opløses til den forkerte adresse, ugyldiggør enhver senere test. Spørg tunnelens resolver, hvad navnet betyder, og sammenlign derefter svaret med den private adresse, som designet tilsigter, i stedet for med et vellykket svar. Et navn, der opløses til en offentlig adresse, er hele problemet, og ingen RDP-ændring retter det:

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

Test derefter porten i stedet for værten. Et fuldført TCP-håndtryk på 3389 adskiller rækkevidde fra alt ovenover:

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

Kør den test fra LAN og fra tunnelen, fordi en forskel mellem de to resultater lokaliserer fejlen til VPN-ruten. To firewalls ligger på ruten, og de er nemme at forveksle: netværket skal tillade klientens tunneladresse at nå værten, og værtens egen firewall skal tillade den samme kilde på den lyttende port. En regel, der er begrænset til LAN-subnettet, dækker ikke VPN-klientpuljen, og det er den mest almindelige årsag til en timeout, som kun fjernbrugere rapporterer. Kontroller reglens omfang i stedet for dens eksistens.

Returvejen fortjener samme kontrol. Svar har brug for en rute tilbage til klientpuljen i stedet for til LAN, og en oversættelse foran værten ændrer den kilde, din log vil vise. Hvis porten svarer den ene vej og ikke den anden, er den manglende halvdel som regel returvejen.

Læs meddelelsen, før du læser konfigurationen

Det tredje stadie er værten, der afviser forbindelsen efter sin egen politik, hvilket ofte ligner en port, der åbner og lukker med det samme. Noget svarede, og det er nyttig information frem for tavshed. Hvis håndtrykket blev fuldført, og sessionen døde med det samme, er netværket fint, og værten bestemmer. Se på tilladelserne for Fjernskrivebord, før du rører netværket igen.

Funktionen kan være aktiveret for maskinen, mens adgangen er begrænset til bestemte grupper, og lytteren kan være bundet på måder, der udelukker den adresse, du ankom på. Netværksniveau-godkendelse tilføjer en port, der fejler, før skrivebordet indlæses, og dens fejltekst adskiller sig fra en forkert adgangskode. Sammenlign klientens meddelelse med værtens hændelseslog, fordi meddelelsen navngiver porten, og loggen navngiver kontoen.

Sessionslogin er sin egen grænse

Godkendelse hører til skrivebordstjenesten, ikke til VPN. Tunnelens identitet og skrivebordskontoen er separate legitimationsoplysninger med separate låsepolitikker, så en fungerende tunnel beviser kun, at tunnelen accepterede dig. Låsning af skrivebordskontoen forstyrrer ikke tunnelen, og det omvendte er også sandt.

Hold begge intakte. Når den private rute mangler, skal du rette ruten, fordi offentliggørelse af lytteren på internettet bytter en rækkeviddefejl for et eksponeret skrivebord. Du bør heller ikke svække sessionens identitetskontroller for at komme forbi en certifikatadvarsel, der dukkede op samtidig. Et selvsigneret certifikat på en RDP-lytter giver en advarsel ved design, så accept af det er en beslutning, ikke et trin.

Tæl forsøgene, før du prøver igen. Låsetærskler for skrivebordet tæller mislykkede login separat fra VPN-fejl, og en klient, der prøver igen på en timer, kan ramme tærsklen, mens du stadig redigerer en regel. Det er den samme parallelle genforsøgsmekanisme, som låser konti efter en adgangskodeændring.

Hvad sessionen kan flytte, og hvor det bliver

Lær den godkendte log-ud-arbejdsgang, før du får brug for den. Lukning af vinduet kan kun afbryde visningen, mens sessionen fortsætter under sin konfigurerede politik, hvilket betyder noget på en delt eller revideret vært. Log ud inde fra sessionen, når politikken forventer det.

Beslut derefter, hvad sessionen må bære, fordi udklipsholder, omdirigerede drev, printeromdirigering og filoverførsel alle flytter data mellem de lokale og fjernede systemer, hvor politikken tillader det. En publiceret applikation, der kører på den anden side, er ikke automatisk en grænse uden download, og en session, der ser skrivebeskyttet ud, kan stadig bære en udklipsholder. Test den virkelige opgave i stedet for forbindelsen: åbn filen, brug applikationen, og bekræft den omdirigering, du har brug for. Microsofts vejledning om at nå et fjernskrivebord udefra beskriver de understøttede eksponeringsmuligheder, og den er en bedre reference end en offentlig lytter, der er tilføjet under pres.