Nuotolinis darbalaukis per VPN: kurioje gedimo stadijoje esate?

Jūsų tunelis veikia, vidinė viki įkeliama, o nuotolinis darbalaukis vis tiek atsisako jungtis. Toks derinys normalus, nes VPN suteikia maršrutą iki prieglobos, o darbalaukio tarnyba turi klausytis, būti leidžiama savo ugniasienės ir būti pasirengusi autentifikuoti paskyrą. Tarp veikiančio tunelio ir naudingos sesijos yra keturios gedimo stadijos, ir kiekviena žlunga su skirtinga žinute. Pirmiausia perskaitykite žinutę, nes ji įvardija stadiją.

Keturi gedimai, kurie atrodo kaip vienas

Stadijos išdėstytos tvarka: vardas išsprendžiamas į privatų adresą, kurį numato dizainas, prievadas atsako į TCP rankos paspaudimą, priegloba priima ryšį pagal savo politiką, o sesijos prisijungimas pavyksta. Kiekviena stadija padaro kitą nepatikrinamą, todėl RDP nustatymų keitimas prieš sutvarkant tinklą tik kelia triukšmą. Simptomas iš naudotojo pusės visais keturiais atvejais atrodo vienodai. Juos skiria tik kliento žinutė.

Veikianti vidinė svetainė neįrodo nė vieno iš keturių. Ji įrodo, kad to paties tinklo priegloba atsakė kitu prievadu su kita tarnyba. Laikykite tai maršrutizavimo įrodymu ir niekuo daugiau.

Tikrinkite iš eilės ir užsirašykite rezultatą. Šokti į prisijungimo ekraną dėl to, kad prievadas atsakė, yra būdas praleisti popietę prie ugniasienės problemos, kurią pirmas žingsnis jau rado.

Ar kas nors klausosi 3389 prievado?

Pradėkite nuo vardo, nes vardas, išsprendžiamas į neteisingą adresą, anuliuoja kiekvieną vėlesnį testą. Paklauskite tunelio sprendėjo, ką reiškia vardas, tada palyginkite atsakymą su privačiu adresu, kurį numato dizainas, o ne su sėkmingu atsakymu. Į viešą adresą išsprendžiamas vardas yra visa problema, ir joks RDP pakeitimas jos nepataisys:

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

Tada tikrinkite prievadą, o ne prieglobą. Užbaigtas TCP rankos paspaudimas 3389 prievade atskiria pasiekiamumą nuo viso to, kas yra aukščiau:

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

Atlikite šį testą iš LAN ir iš tunelio, nes skirtumas tarp dviejų rezultatų lokalizuoja gedimą VPN kelyje. Kelyje yra dvi ugniasienės ir jas lengva supainioti: tinklas turi leisti kliento tunelio adresui pasiekti prieglobą, o prieglobos ugniasienė turi leisti tą patį šaltinį klausymosi prievade. Taisyklė, apribota LAN potinkliu, neapima VPN klientų telkinio, ir tai yra dažniausia priežastis, kodėl apie laiko limitą praneša tik nuotoliniai naudotojai. Tikrinkite taisyklės apimtį, o ne jos buvimą.

Grįžtamasis kelias nusipelno to paties patikrinimo. Atsakymams reikia maršruto atgal į klientų telkinį, o ne į LAN, o vertimas prieš prieglobą pakeičia šaltinį, kurį rodys jūsų žurnalas. Jei prievadas atsako viena kryptimi, o kita ne, trūkstama pusė paprastai yra grįžtamasis kelias.

Perskaitykite žinutę prieš skaitydami konfigūraciją

Trečioji stadija yra priegloba, atmetanti ryšį pagal savo politiką, o tai dažnai atrodo kaip prievadas, kuris iškart atsiveria ir užsidaro. Kažkas atsakė, ir tai naudinga informacija, o ne tyla. Jei rankos paspaudimas baigtas, o sesija iškart mirė, tinklas tvarkingas ir sprendžia priegloba. Pažiūrėkite nuotolinio darbalaukio leidimus prieš vėl liesdami tinklą.

Funkcija gali būti įjungta mašinai, nors prieiga apribota tam tikroms grupėms, o klausytojas gali būti susietas taip, kad neapimtų adreso, iš kurio atėjote. Tinklo lygmens autentifikavimas prideda vartus, kurie žlunga prieš įkeliant darbalaukį, ir jų klaidos tekstas skiriasi nuo neteisingo slaptažodžio. Palyginkite kliento žinutę su prieglobos įvykių žurnalu, nes žinutė įvardija vartus, o žurnalas – paskyrą.

Sesijos prisijungimas yra atskira riba

Autentifikavimas priklauso darbalaukio tarnybai, o ne VPN. Tunelio tapatybė ir darbalaukio paskyra yra atskiri kredencialai su atskiromis užrakinimo politikomis, todėl veikiantis tunelis įrodo tik tai, kad tunelis jus priėmė. Darbalaukio paskyros užrakinimas netrukdo tuneliui, ir atvirkščiai taip pat tiesa.

Saugokite abu nepažeistus. Kai trūksta privataus maršruto, taisykite maršrutą, nes klausytojo paskelbimas internete iškeičia pasiekiamumo klaidą į atvirą darbalaukį. Nesusilpninkite ir sesijos tapatybės patikrinimų, kad apeitumėte tuo pačiu metu pasirodžiusį sertifikato įspėjimą. Savarankiškai pasirašytas sertifikatas RDP klausytojui iš prigimties duoda įspėjimą, todėl jį priimti yra sprendimas, o ne žingsnis.

Suskaičiuokite bandymus prieš bandydami dar kartą. Darbalaukio užrakinimo slenksčiai nesėkmingus prisijungimus skaičiuoja atskirai nuo VPN gedimų, o klientas, bandantis dar kartą pagal laikmatį, gali viršyti slenkstį, kol jūs dar redaguojate taisyklę. Tai tas pats lygiagrečių pakartotinių bandymų mechanizmas, kuris užrakina paskyras po slaptažodžio pakeitimo.

Ką sesija gali perkelti ir kur tai lieka

Išmokite patvirtintą atsijungimo eigą, kol jos dar neprireikė. Langą uždarius gali būti atjungiamas tik vaizdas, o sesija toliau veikia pagal savo sukonfigūruotą politiką, kas svarbu bendroje ar audituotoje priegloboje. Atsijunkite iš sesijos vidaus, kai politika to tikisi.

Tada nuspręskite, ką sesija gali pernešti, nes iškarpinė, nukreipti diskai, spausdintuvo nukreipimas ir failų perdavimas perkelia duomenis tarp vietinės ir nuotolinės sistemų ten, kur politika leidžia. Paskelbta programa, veikianti kitoje pusėje, nėra automatiškai riba be atsisiuntimo, o sesija, kuri atrodo skirta tik skaitymui, vis tiek gali pernešti iškarpinę. Tikrinkite tikrą užduotį, o ne ryšį: atidarykite failą, naudokitės programa ir patvirtinkite reikiamą nukreipimą. Microsoft nurodymai, kaip pasiekti nuotolinį darbalaukį iš išorės aprašo palaikomas eksponavimo parinktis, ir tai geresnė nuoroda nei viešas klausytojas, pridėtas esant spaudimui.