Desktopi në distancë përmes një VPN: në cilën dështim jeni?

Tuneli juaj është aktiv, wiki i brendshëm ngarkohet, dhe Desktopi në distancë vazhdon të refuzojë lidhjen. Ky kombinim është normal, sepse VPN-ja ofron një rrugë drejt hostit ndërsa shërbimi i desktopit duhet të dëgjojë, të lejohet nga firewall-i i vet dhe të jetë i gatshëm të vërtetojë llogarinë. Katër faza dështimi qëndrojnë midis një tuneli funksional dhe një sesioni të përdorshëm, dhe secila dështon me një mesazh tjetër. Lexoni së pari mesazhin, sepse ai emërton fazën.

Katër dështime që duken si një

Fazat janë të renditura: emri zgjidhet në adresën private që projekti synon, porta përgjigjet ndaj një shtrëngimi duarsh TCP, hosti pranon lidhjen sipas politikës së vet, dhe hyrja në sesion ka sukses. Secila fazë e bën të paprovueshme atë pasardhëse, prandaj ndryshimi i cilësimeve RDP përpara se rrjeta të rregullohet prodhon vetëm zhurmë. Simptoma duket identike nga ana e përdoruesit në të katër rastet. Vetëm mesazhi i klientit i ndan ato.

Një faqe interneti e brendshme që funksionon nuk provon asnjë nga të katërtat. Ajo provon se një host në të njëjtën rrjetë u përgjigj në një portë tjetër me një shërbim tjetër. Trajtojeni si provë për rrugëzimin dhe asgjë më shumë.

Provoni sipas radhës dhe shkruani rezultatin. Kërcimi te ekrani i hyrjes sepse porta u përgjigj është mënyra për të kaluar një pasdite me një problem firewall-i që hapi i parë e kishte lokalizuar tashmë.

A dëgjon diçka në 3389?

Filloni me emrin, sepse një emër që zgjidhet në adresën e gabuar zhvlerëson çdo provë të mëvonshme. Pyetni zgjidhësin e tunelit çfarë do të thotë emri, pastaj krahasoni përgjigjen me adresën private që projekti synon, jo me një përgjigje të suksesshme. Një emër që zgjidhet në një adresë publike është i gjithë problemi, dhe asnjë ndryshim RDP nuk do ta rregullojë:

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

Pastaj provoni portën, jo hostin. Një shtrëngim duarsh TCP i përfunduar në 3389 ndan arritshmërinë nga gjithçka mbi të:

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

Kryeni atë provë nga LAN dhe nga tuneli, sepse një ndryshim midis dy rezultateve e lokalizon defektin në rrugën e VPN-së. Në rrugë qëndrojnë dy firewall-e dhe është e lehtë t'i ngatërrosh: rrjeta duhet të lejojë adresën e tunelit të klientit të arrijë hostin, dhe firewall-i i vetë hostit duhet të lejojë të njëjtin burim në portën që dëgjon. Një rregull i kufizuar në nënrrjetën LAN nuk mbulon grupin e klientëve VPN, dhe kjo është shkaku më i zakonshëm i një skadimi kohe për të cilin raportojnë vetëm përdoruesit në distancë. Kontrolloni shtrirjen, jo ekzistencën e rregullit.

Rruga e kthimit meriton të njëjtin kontroll. Përgjigjet kanë nevojë për një rrugë kthimi te grupi i klientëve dhe jo te LAN, dhe një përkthim përpara hostit ndryshon burimin që do të tregojë regjistri juaj. Nëse porta përgjigjet në një drejtim dhe jo në tjetrin, gjysma që mungon zakonisht është rruga e kthimit.

Lexoni mesazhin përpara se të lexoni konfigurimin

Faza e tretë është hosti që refuzon lidhjen sipas politikës së vet, çka shpesh duket si një portë që hapet dhe mbyllet menjëherë. Diçka u përgjigj, dhe ky është informacion i dobishëm në vend të heshtjes. Nëse shtrëngimi i duarve përfundoi dhe sesioni vdiq menjëherë, rrjeta është në rregull dhe hosti vendos. Shikoni lejet e Desktopit në distancë përpara se të prekni përsëri rrjetën.

Veçoria mund të jetë e aktivizuar për makinën ndërsa hyrja është e kufizuar te grupe të caktuara, dhe dëgjuesi mund të jetë i lidhur në mënyra që përjashtojnë adresën nga e cila keni ardhur. Vërtetimi në nivel rrjete shton një portë që dështon përpara se desktopi të ngarkohet, dhe teksti i gabimit të tij ndryshon nga një fjalëkalim i gabuar. Krahasoni mesazhin e klientit me regjistrin e ngjarjeve të hostit, sepse mesazhi emërton portën dhe regjistri llogarinë.

Hyrja në sesion është kufi më vete

Vërtetimi i takon shërbimit të desktopit, jo VPN-së. Identiteti i tunelit dhe llogaria e desktopit janë kredenciale të ndara me politika bllokimi të ndara, prandaj një tunel funksional provon vetëm se tuneli ju pranoi. Bllokimi i llogarisë së desktopit nuk e shqetëson tunelin, dhe e kundërta është gjithashtu e vërtetë.

Mbajini të dyja të paprekura. Kur mungon rruga private, rregulloni rrugën, sepse publikimi i dëgjuesit në internet shkëmben një defekt arritshmërie me një desktop të ekspozuar. Mos dobësoni as kontrollet e identitetit të sesionit për të kaluar një paralajmërim certifikate që u shfaq në të njëjtën kohë. Një certifikatë e vetë-nënshkruar në një dëgjues RDP prodhon një paralajmërim sipas projektit, prandaj pranimi i saj është vendim dhe jo hap.

Numëroni përpjekjet përpara se të riprovoni. Pragjet e bllokimit të desktopit numërojnë hyrjet e dështuara ndaras nga dështimet e VPN-së, dhe një klient që riprovoi me kohëmatës mund të kalojë pragun ndërsa ju ende po modifikoni një rregull. Është i njëjti mekanizëm përpjekjesh paralele që bllokon llogaritë pas një ndryshimi fjalëkalimi.

Çfarë mund të zhvendosë sesioni, dhe ku mbetet

Mësoni rrjedhën e miratuar të daljes përpara se t'ju duhet. Mbyllja e dritares mund të shkëpusë vetëm pamjen ndërsa sesioni vazhdon sipas politikës së konfiguruar, çka ka rëndësi në një host të përbashkët ose të audituar. Dilni nga brenda sesionit kur politika e pret këtë.

Pastaj vendosni çfarë mund të mbajë sesioni, sepse clipboard-i, disqet e ridrejtuara, ridrejtimi i printerit dhe transferimi i skedarëve zhvendosin të dhëna midis sistemeve lokal dhe në distancë aty ku politika lejon. Një aplikacion i publikuar që ekzekutohet në anën tjetër nuk është automatikisht kufi pa shkarkim, dhe një sesion që duket vetëm-lexim mund të mbajë prapëseprapë një clipboard. Provoni detyrën reale dhe jo lidhjen: hapni skedarin, përdorni aplikacionin dhe konfirmoni ridrejtimin që ju nevojitet. Udhëzimet e Microsoft për të arritur një desktop në distancë nga jashtë përshkruajnë opsionet e ekspozimit të mbështetura, dhe janë një referencë më e mirë sesa një dëgjues publik i shtuar nën presion.