Ngrirja e RDP-së përmes VPN: hyrja ende funksionon, prandaj provoni transportin

Kur imazhi ndalon së përditësuari por miu vazhdon të rrëshqasë nëpër desktopin në distancë, përfundimi i dukshëm është se VPN-ja ra. Ky përfundim zakonisht është i gabuar. Një kornizë e ngrirë me hyrje funksionale do të thotë që sesioni dhe kanali i tij i hyrjes janë gjallë, gjë që e shtyn defektin drejt transportit të grafikës dhe jo drejt rrugëzimit ose kredencialeve. Dy vëzhgime të shpejta ndajnë tre dështimet që përdoruesit i përshkruajnë me të njëjtën fjalë.

Çfarë nuk ju thotë ngrirja

Desktopi në distancë transporton hyrjen dhe përditësimet e ekranit përmes TCP 3389, dhe klientët aktualë Windows mund të shtojnë një transport UDP për pjesën e rrjedhës me ngarkesë të madhe grafike. Në një tunel që fragmenton ose hedh datagrame më të mëdha, kanali i besueshëm vazhdon të mbajë shtypjet e tasteve ndërsa kanali i grafikës ngec. Rezultati është kombinimi i çuditshëm i një imazhi të ngecur dhe një tastiere që përgjigjet. Kjo shpjegon gjithashtu pse rilidhja ndonjëherë e shëron simptomën për një minutë dhe pastaj e kthen atë.

Një sesion që shkëputet dhe rilidhet është një defekt tjetër, dhe një që nuk hapet fare është i treti. Emërtimi i formës së pari ju pengon të provoni shtresën e gabuar.

Ndani tre dështimet me dy komanda

Përjashtimi i arritshmërisë është i lirë. Provoni portën RDP nga klienti, pastaj lexoni gjendjen e sesionit në host.

Test-NetConnection rdp-host.example.com -Port 3389
query user /server:rdp-host

Një test TCP i dështuar do të thotë që sesioni nuk u hap kurrë, prandaj trajtojeni si problem firewalls, shtrirjeje ose shërbimi dhe jo si ngrirje. Një test i suksesshëm me një sesion aktiv konfirmon se kanali i kontrollit ekziston, gjë që është pikërisht rasti i imazhit të ngrirë. Ekzekutoni pyetjen e hostit nga një llogari që ka leje të shohë sesionet, sepse një gabim lejeje duket si listë boshe. Regjistroni ID-në dhe gjendjen e sesionit, pasi një sesion i shkëputur që mban ID-në e tij nuk është i njëjtë me një aktiv.

Fikni transportin UDP dhe krahasoni

Nëse vetëm shfaqja ngec, krahasoni transportet e klientëve me një ndryshim në herë. Klienti i integruar dhe klienti Store nuk ndajnë të njëjtin stivë, dhe politika më poshtë heq UDP nga klienti i integruar.

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client" /v fClientDisableUDP

Vlera 1 do të thotë që UDP është tashmë i fikur për atë klient, prandaj një ngrirje që i mbijeton rregullimit nuk është problem i rrugës UDP. Kur vlera mungon, aktivizoni politikën, rilidheni dhe përsëritni saktësisht veprimin që u ngrirë më parë. Provoni klientin Store si hap të veçantë në vend që të kombinoni të dy ndryshimet, përndryshe nuk do të dini cili kishte rëndësi. Mbani versionin e klientit në shënimet tuaja, pasi sjellja e transportit ka ndryshuar ndër versionet e Windows.

Kur një host ngrin por të tjerët janë mirë

Një host i vetëm që dështon në një nënrrjet përndryshe të shëndoshë tregon larg tunelit. Kontrolloni MTU-në e rrugës dhe stivën e shfaqjes në distancë përpara se të prekni cilësimet e VPN.

ping -f -l 1472 rdp-host.example.com

Një përgjigje vërteton se rruga mbart një paketë me madhësi të plotë pa fragmentim në atë madhësi, ndërsa një dështim me flamurin e mosfragmentimit sugjeron që MTU-ja e tunelit ka nevojë për vëmendje. Nëse kalojnë 1472 bajt dhe ngrin vetëm ai host, shikoni drejtuesin e grafikës dhe ngarkesën e tij dhe jo rrjetin. Një kopje e shpejtë skedari në të njëjtën makinë thotë diçka për xhiron dhe jo për kanalin e grafikës së RDP. Ndryshoni një variabël në herë dhe përsëritni të njëjtin veprim në ekran që krahasimi të ketë kuptim.

Nëse sesioni nuk hapet fare, ndaloni këtu, sepse kjo është arritshmëri dhe jo ngrirje. Përndryshe mbani cilësimin e transportit që ndryshoi simptomën dhe regjistrojeni atë me versionin e klientit.