Bakit Nag-freeze ang RDP Kapag Kumokonekta sa VPN ang Remote na Computer

Nasa loob ka ng RDP window, nasa screen ang desktop, at pinindot mo ang Connect sa VPN client na tumatakbo sa remote na makinang iyon. Pagkalipas ng ilang segundo, nag-freeze ang window at pagkatapos ay nagsara. Bumangon ang tunnel, at iyon mismo ang itatala ng VPN log, at iyon ang pinakamaliit na kapaki-pakinabang na katotohanan sa buong insidente. Namatay ang session dahil binago ng makinang kausap mo ang paraan ng pagtugon sa iyo, kaya suriin ang pabalik na landas bago hawakan ang tunnel.

Itala ang endpoint na aktwal na ginagamit ng iyong session

Ang address na itina-type sa iyong RDP client ay hindi laging ang address na tinutugon ng remote na computer. Maaaring isulat muli ito ng NAT, RD Gateway o load balancer sa harap ng host, at ang pabalik na landas ay tinutukoy ng source address na nakikita ng remote na makina sa naitatag na koneksyon. Kapag nagkamali ka rito, hahanapin mo ang rutang hindi kailanman nasangkot.

Sa remote na computer, bago makonekta ang VPN, ilista ang mga naitatag na session at basahin ang peer address mula sa table. Pagkatapos, isulat ito sa labas ng makinang iyon, dahil hindi mo na ito mababasa kapag bumagsak ang session.

Get-NetTCPConnection -LocalPort 3389 -State Established |
  Select-Object LocalAddress, RemoteAddress, RemotePort

Ituring ang address na iyon bilang bagay na dapat manatiling maabot. Kung ito ay pribadong address sa VLAN ng pamamahala, dapat hayaan ng tunnel ang landas na iyon. Kung ito ay pampublikong address, dapat lumabas ang tugon sa parehong interface na nagdala ng kahilingan papasok.

Basahin ang rutang tumutugon sa endpoint na iyon

Pumipili ang Windows ng interface para sa bawat destinasyon, at Find-NetRoute ay nagpapakita ng desisyong gagawin nito ngayon. Patakbuhin ito sa peer address bago kumonekta, pagkatapos ay muli habang nakataas ang tunnel, at ihambing ang interface index at susunod na hop sa dalawang sagot. Ang pagbabago ng interface ang buong depekto sa isang linya ng output.

Find-NetRoute -RemoteIPAddress 203.0.113.24
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-VpnConnection -Name "Work VPN" | Select-Object SplitTunneling, Routes

Ang full-tunnel profile ay naglalagay ng default na ruta sa tunnel, gaya ng inilalarawan ng gabay ng Windows sa VPN routing, kaya lumalabas na ngayon ang bawat sagot sa VPN at nakadepende sa kung ang kabilang panig ay nagru-ruta pabalik sa iyong client. Ang split-tunnel profile ay mas ligtas bilang default ngunit hindi immune, dahil ang partikular na ruta na sumasaklaw sa peer address ay maaari pa ring manaig sa pisikal na default na ruta. Sa anumang kaso, ang tanong ay pareho: kapag bumangon ang tunnel, nire-resolve pa ba ang peer address sa interface na nagdala ng session papasok?

Kung hindi, ang pagwawasto ay nasa profile o sa tahasang ruta ng pagbubukod na inaprubahan ng may-ari ng patakaran ng VPN. Ang manu-manong pag-edit ng routing table sa production host habang may insidente ang paraan kung paano nagiging walang dokumentong configuration ang pansamantalang solusyon.

Panoorin ang pagbabago ng profile ng firewall

Ang bagong interface ay inuuri kapag lumitaw ito, at itinatakda ng pag-uuri kung aling profile ng firewall ang pagbabatayan ng trapiko nito. Ang tunnel adapter na nahuhulog sa kategoryang Public ay maaaring tahimik na ihinto ang papasok na RDP kahit mukhang perpekto ang routing table. Ito ang ikalawang mode ng pagpalya, at nagbubunga ito ng ibang sintomas: tama ang ruta, dumarating ang mga packet, at tinatanggihan ng host ang koneksyon.

Get-NetConnectionProfile
Get-NetFirewallProfile | Select-Object Name, Enabled
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object Name, Enabled, Profile

Ihambing ang profile na nakakabit sa interface ng tunnel sa mga profile na pinagtuunan ng mga patakaran ng Remote Desktop. Ang patakarang pinagana para sa Domain at Private lamang ay walang ginagawa para sa interface na inuring Public, at walang pagwawasto ng ruta ang makakabago niyon. Ang ilang VPN client ay nililimitahan din ayon sa disenyo ang pag-access sa lokal na subnet, na nagbubunga ng parehong anyo ng pagpalya mula sa ibang kontrol.

Subukan ang paglipat mula sa lugar na makakabalik ka

Gawin ang buong pagkakasunod-sunod mula sa out-of-band console o pangalawang landas ng pamamahala, sa ayos na ito: kumpirmahin ang umiiral na session, ikonekta ang VPN, buksan ang bagong session, pagkatapos idiskonekta ang VPN at buksan ang isa pa. Bawat hakbang ay sumusubok ng ibang paglipat, at ang unang pumapalya ang magsasabi kung aling kontrol ang responsable.

Plano ang rollback bago magsimula, halimbawa isang naka-iskedyul na gawain na nagpapatakbo ng rasdial "Work VPN" /disconnect pagkatapos ng takdang agwat. Ginagawa nitong limang minutong pagkaantala ang nawalang session kaysa sa pagbisita sa lugar, at ito ang pinakamurang seguro sa buong pamamaraan.

Bumalik sa loob kapag wala na ang session

Kung hindi na maabot ang host, itigil ang pagsubok ng mga bagong koneksyon sa RDP mula sa parehong client at gamitin ang channel ng pagbangon na taglay na ng kapaligiran: RD Gateway, console ng hypervisor o interface ng pamamahala na out-of-band. Ipatupad sa taong may access sa console ang parehong mga utos Find-NetRoute at Get-NetConnectionProfile, upang manatili ang ebidensya pagkatapos ng pagbangon.

Pagkatapos, magpasya sa permanenteng kaayusan at hindi sa pinakamabilis. Alinman sa ang path ng pamamahala ay hayagang pinapanatili ng VPN profile, o lumilipat ang pamamahala sa channel na hindi umaasa sa default na ruta ng host. Pareho itong maipagtatanggol; ang ruta ng host na may hinulaang gateway ay hindi. Isulat kung alin ang pinili mo, at itala ang peer address na kailangang manatili.