Slutar RDP fungera efter installation av en VPN-klient? Det är brandväggen

Några minuter efter att en konsument-VPN-klient har installerat klart säger portalen fortfarande att VM:en kör, den offentliga IP-adressen har inte ändrats och RDP svarar inte. Folk antar vanligtvis att VM:en har kraschat eller att nätverkssäkerhetsgruppen har ändrats, och båda är oftast fel. Det som har ändrats är den Windows-brandväggsprofil maskinen står i, och RDP-regeln som tidigare passade passar inte längre. Reparationen börjar med att skaffa ett skal via en väg som inte är beroende av RDP.

VM:en kör; regeln passar inte längre

Brandväggsregler i Windows bär en uppsättning profiler, och en regel som är begränsad till Privat eller Domän har ingen verkan medan maskinen står i den Offentliga profilen. VPN-installationer lägger till adaptrar och rutter, och flera av dem skärper Offentlig som en bieffekt. Lyssnaren förblir bunden till 3389 och paketen kommer fortfarande in, men profilavvikelsen kastar dem.

Strömtillstånd och nåbarhet är separata fakta, och en körande VM med stängd port ser utifrån precis ut som en som har kraschat.

Testa porten innan du ändrar något. Ett anslutningsförsök till 3389 som tar timeout medan ett kommando till gästagenten fortfarande returnerar utdata pekar på värdens brandvägg. En port som svarar medan RDP fortfarande misslyckas betyder att felet sitter ovanför nätverkslagret, och den här reparationen rör det inte. Notera vilket av de två fallen du såg, eftersom resten av planen hänger på det.

Två portar stängs oberoende av varandra

Plattformspolicyn går först: nätverkssäkerhetsgruppen ser paketet innan gästen gör det. Den ordningen gör en perfekt NSG-post oanvändbar när värden kastar paketet, och en öppen värdregel oanvändbar när plattformen nekar den. Behandla dem som separata portar och testa var och en för sig.

Läs NSG:s gällande regler i portalen eller i CLI och jämför dem sedan med gästens egna regler. Anta inte att den senaste ändringen du minns är den som trädde i kraft.

En konsumentklient kan också installera en filterdrivrutin eller en kill switch som blockerar trafik under Windows-brandväggen. Om brandväggsreglerna ser korrekta ut och porten fortfarande misslyckas är det lagret nästa misstänkta.

Använd gästagenten som väg tillbaka

Två funktioner för fjärrkörning, Run Command och Custom Script Extension, körs inne i gästen via plattformsagenten. Ingen av dem behöver RDP, så brandväggsfelet påverkar dem inte. Båda returnerar skriptets utdata, vilket gör dem till en diagnostikkanal och samtidigt en reparationskanal.

Läs den aktiva profilen och RDP-regeln innan du ändrar någon av dem:

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

Att återaktivera inkommande regler på den profilen är en tillfällig åtgärd, inte ett mål. Använd den för att få en session och stäng sedan gapet ordentligt:

Set-NetFirewallProfile -Name Public -AllowInboundRules True

Den brytaren öppnar varje inkommande regel på profilen, inte bara RDP. När du har en session ersätter du den med en begränsad regel och återställer de inställningar du faktiskt vill ha. Om agenten också är otillgänglig är en seriell konsol eller en återuppbyggd disk reservvägen, och det är det praktiska skälet att hålla agenten frisk.

Begränsa gapet innan du stänger sessionen

Den tillfälliga profiländringen är en dörr som hålls öppen för varje inkommande regel på den profilen. Ersätt den med en regel som är begränsad till din källadress och RDP-porten, och bekräfta sedan att profilen är tillbaka i avsett skick. Gör detta medan du fortfarande har sessionen, eftersom nästa misstag kanske inte går att ångra på distans. Håll en andra administrativ väg, som Bastion eller en seriell konsol, redo under ändringen.

Bekräfta resultatet från din arbetsstation med ett porttest, och inifrån gästen med regellistan:

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

Slå på brandväggsloggning under testets gång. En enda rad om ett kastat paket som nämner 3389 och den aktiva profilen svarar på frågan snabbare än ännu en omstart.

Förhindra nästa installation från att göra det igen

Om den värden inte har någon anledning att köra klienten, avinstallera den. En installerad klient är en stående inbjudan till att nästa uppdatering skriver om profilen igen, och nästa person kommer att felsöka samma avbrott från portalen.

Ta en ögonblicksbild av disken innan du låter något skriva om nätverksinställningarna, och håll en andra administrativ väg redo innan du behöver den.

Notera vad installationen ändrade: adaptrar, rutter, brandväggsprofiler, filterdrivrutiner och tjänster. Den anteckningen gör nästa incident till ett känt mönster i stället för en ny utredning. När VM:en behöver en tunnel till exakt en tjänst, sätt klienten på din arbetsstation eller bygg en förbindelse mellan platser i stället för att installera en laptopprodukt på servern. Konsumentklienter riktar sig till laptops, och en server som du administrerar på distans är inte det.