Humihinto ang RDP pagkatapos i-install ang isang VPN client? Ang firewall ang may kasalanan

Ilang minuto matapos matapos ng isang consumer VPN client ang pag-install, sinasabi pa rin ng portal na tumatakbo ang VM, hindi nagbago ang pampublikong IP, at hindi tumutugon ang RDP. Karaniwang iniisip ng mga tao na nag-crash ang VM o nagbago ang network security group, at kadalasan ay mali ang dalawa. Ang nagbago ay ang profile ng firewall ng Windows kung saan naroon ang makina, at ang panuntunan ng RDP na dating tugma ay hindi na tugma. Nagsisimula ang pag-aayos sa pagkuha ng shell sa isang landas na hindi umaasa sa RDP.

Tumatakbo ang VM; hindi na tugma ang panuntunan

Ang mga panuntunan ng firewall sa Windows ay may set ng profile, at ang panuntunang limitado sa Pribado o Domain ay walang epekto habang ang makina ay nasa pampublikong profile. Nagdadagdag ang mga installer ng VPN ng adapter at ruta, at marami sa kanila ay pinapalakas ang Pampubliko bilang side effect. Nananatiling nakatali ang listener sa 3389 at dumarating pa rin ang mga packet, ngunit itinatapon sila ng pagkakaiba ng profile.

Ang estado ng kuryente at ang maabot ay magkaibang katotohanan, at ang tumatakbong VM na may saradong port ay mukhang eksaktong katulad ng nag-crash kapag tiningnan mula sa labas.

Subukan ang port bago baguhin ang anuman. Ang pagtatangkang kumonekta sa 3389 na nag-time out habang nagbabalik pa rin ng output ang utos ng guest agent ay tumuturo sa firewall ng host. Ang port na tumutugon pero nabibigo pa rin ang RDP ay nangangahulugang nasa itaas ng network layer ang depekto, at hindi ito gagalawin ng pag-aayos na ito. Itala kung alin sa dalawang kaso ang nakita mo, dahil nakasalalay dito ang natitirang plano.

Dalawang gate ang nagsasara nang nakapag-iisa

Nauna ang patakaran ng platform: nakikita ng network security group ang packet bago ang guest. Dahil sa ayos na iyon, walang silbi ang perpektong NSG entry kapag itinapon ng host ang packet, at walang silbi ang bukas na panuntunan ng host kapag tinanggihan ito ng platform. Ituring silang magkahiwalay na gate at subukan ang bawat isa nang mag-isa.

Basahin ang mabisang panuntunan ng NSG sa portal o CLI, pagkatapos ay ihambing sa sariling panuntunan ng guest. Huwag ipagpalagay na ang huling pagbabagong natatandaan mo ang siyang nagkabisa.

Ang isang consumer client ay maaari ring mag-install ng filter driver o kill switch na humaharang sa trapiko sa ilalim ng firewall ng Windows. Kung mukhang tama ang mga panuntunan ng firewall at nabibigo pa rin ang port, ang layer na iyon ang susunod na hinala.

Gamitin ang guest agent bilang daan pabalik

Dalawang feature ng remote execution, ang Run Command at Custom Script Extension, ay tumatakbo sa loob ng guest sa pamamagitan ng platform agent. Wala sa kanila ang nangangailangan ng RDP, kaya hindi sila apektado ng pagkakamali sa firewall. Pareho silang nagbabalik ng output ng script, kaya nagiging channel sila ng diagnosis at pag-aayos nang sabay.

Basahin ang aktibong profile at ang panuntunan ng RDP bago baguhin ang alinman sa dalawa:

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

Ang muling pagpapagana ng inbound na panuntunan sa profile na iyon ay pansamantalang hakbang, hindi destinasyon. Gamitin ito para makakuha ng session, pagkatapos ay isara nang maayos ang butas:

Set-NetFirewallProfile -Name Public -AllowInboundRules True

Binubuksan ng switch na iyon ang bawat inbound na panuntunan sa profile, hindi lang RDP. Kapag mayroon nang session, palitan ito ng limitadong panuntunan at ibalik ang mga setting na talagang gusto mo. Kung hindi rin available ang agent, ang serye na console o muling itinayong disk ang fallback, at iyon ang praktikal na dahilan para panatilihing malusog ang agent.

Paliitin ang butas bago isara ang session

Ang pansamantalang pagbabago ng profile ay isang pinto na pinananatiling bukas para sa bawat inbound na panuntunan ng profile na iyon. Palitan ito ng panuntunang limitado sa iyong source address at sa port ng RDP, pagkatapos ay kumpirmahin na bumalik ang profile sa nilalayong estado. Gawin ito habang mayroon ka pang session, dahil ang susunod na pagkakamali ay maaaring hindi na maibalik mula sa malayo. Panatilihing nakahanda ang pangalawang administratibong landas tulad ng Bastion o serye na console habang nagbabago.

Kumpirmahin ang resulta mula sa iyong workstation gamit ang port test, at mula sa loob ng guest gamit ang listahan ng panuntunan:

Test-NetConnection -ComputerName 203.0.113.25 -Port 3389
Get-NetFirewallRule -DisplayName "RDP from admin" | Get-NetFirewallPortFilter

Buhayin ang pag-log ng firewall sa buong tagal ng test. Ang isang linya tungkol sa itinapong packet na nagbabanggit ng 3389 at ng aktibong profile ay sumasagot sa tanong nang mas mabilis kaysa sa isa pang reboot.

Pigilan ang susunod na installer na gawin itong muli

Kung walang dahilan ang host na iyon para patakbuhin ang client, i-uninstall ito. Ang naka-install na client ay isang permanenteng imbitasyon para muling isulat ng susunod na update ang profile, at ang susunod na tao ay magde-debug ng parehong pagkawala mula sa portal.

Kumuha ng snapshot ng disk bago hayaang may magsulat muli ng mga setting ng network, at panatilihing nakahanda ang pangalawang administratibong landas bago mo ito kailanganin.

Itala kung ano ang binago ng installer: adapter, ruta, profile ng firewall, filter driver at serbisyo. Ang rekord na iyon ay ginagawang kilalang pattern ang susunod na insidente sa halip na bagong imbestigasyon. Kapag kailangan ng VM ng tunnel sa eksaktong isang serbisyo, ilagay ang client sa iyong workstation o bumuo ng site-to-site link sa halip na mag-install sa server ng produktong para sa laptop. Ang mga consumer client ay nakatuon sa laptop, at ang server na pinamamahalaan mo mula sa malayo ay hindi ganoon.