Varför RDP fryser när den externa datorn ansluter till ett VPN

Du är inne i RDP-fönstret, skrivbordet syns på skärmen och du trycker Connect i VPN-klienten som körs på den där externa maskinen. Några sekunder senare fryser fönstret och stängs. Tunneln kom upp, vilket är exakt vad VPN-loggen kommer att rapportera, och det är det minst användbara faktumet i hela incidenten. Sessionen dog eftersom maskinen du pratade med ändrade sättet den svarar dig på, så gå igenom returvägen innan du rör tunneln.

Notera slutpunkten som din session faktiskt använder

Adressen som skrivs in i RDP-klienten är inte nödvändigtvis den adress som den externa datorn svarar på. NAT, en RD Gateway eller en lastbalanserare framför värden kan skriva om den, och returvägen bestäms av källadressen som den externa maskinen ser på den upprättade anslutningen. Tar du fel här letar du efter en rutt som aldrig var inblandad.

På den externa datorn, innan VPN:et är anslutet, lista de upprättade sessionerna och läs peer-adressen ur tabellen. Skriv sedan ner den någonstans utanför den maskinen, för du kan inte läsa den efter att sessionen faller.

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

Behandla den adressen som det som måste förbli nåbart. Är det en privat adress på ett administrations-VLAN måste tunneln lämna den vägen i fred. Är det en publik adress måste svaret gå ut genom samma gränssnitt som tog in begäran.

Läs rutten som svarar på den slutpunkten

Windows väljer ett gränssnitt per destination, och Find-NetRoute visar det beslut det skulle fatta just nu. Kör den mot peer-adressen innan du ansluter, sedan igen med tunneln uppe, och jämför gränssnittsindex och nästa hopp i de två svaren. Ett byte av gränssnitt är hela felet på en rad utdata.

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

En fulltunnelprofil installerar en standardrutt genom tunneln, som Windows-guiden för VPN-routing beskriver, så varje svar går nu ut genom VPN:et och beror på att andra sidan routar tillbaka till din klient. En delad tunnelprofil är säkrare som standard men inte immun, eftersom en specifik rutt som täcker peer-adressen fortfarande kan slå den fysiska standardrutten. Hur som helst är frågan identisk: när tunneln kommer upp, löses peer-adressen fortfarande till det gränssnitt som tog in sessionen?

Om inte hör rättelsen hemma i profilen eller i en uttrycklig undantagsrutt som godkänts av ägaren till VPN-policyn. Att redigera routingtabellen för hand på en produktionsvärd under en incident är hur en tillfällig lösning blir odokumenterad konfiguration.

Håll koll på ändringen av brandväggsprofilen

Ett nytt gränssnitt klassas när det dyker upp, och klassningen avgör vilken brandväggsprofil dess trafik bedöms mot. En tunneladapter som hamnar i kategorin Public kan tyst stoppa inkommande RDP även om routingtabellen ser perfekt ut. Det är det andra felläget, och det ger ett annat symptom: rutten är rätt, paketen kommer fram och värden nekar anslutningen.

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

Jämför profilen som är knuten till tunnelgränssnittet med de profiler som Remote Desktop-reglerna är begränsade till. En regel som bara är aktiverad för Domain och Private gör ingenting för ett gränssnitt som klassats som Public, och ingen ruttkorrigering ändrar det. Vissa VPN-klienter begränsar också åtkomsten till det lokala subnätet av design, vilket ger samma felform från en annan kontroll.

Testa övergången från en plats du kan komma tillbaka från

Gör hela sekvensen från en out-of-band-konsol eller en andra administrationsväg, i den här ordningen: bekräfta den befintliga sessionen, anslut VPN:et, öppna en ny session, koppla sedan från VPN:et och öppna ännu en. Varje steg testar en annan övergång, och det första som misslyckas berättar vilken kontroll som är ansvarig.

Planera återrullningen innan du börjar, till exempel en schemalagd uppgift som kör rasdial "Work VPN" /disconnect efter ett fast intervall. Det gör en förlorad session till ett fem minuters avbrott i stället för ett besök på plats, och det är den billigaste försäkringen i hela proceduren.

Kom in igen när sessionen redan är borta

Om värden redan är onåbar, sluta försöka med nya RDP-anslutningar från samma klient och använd den återställningskanal som miljön redan har: en RD Gateway, en hypervisor-konsol eller ett out-of-band-administrationsgränssnitt. Be personen med konsolåtkomst att köra samma kommandon Find-NetRoute och Get-NetConnectionProfile, så att bevisen överlever återställningen.

Bestäm sedan den permanenta ordningen i stället för den snabbaste. Antingen bevaras administrationsvägen uttryckligen av VPN-profilen, eller så flyttas administrationen till en kanal som inte beror på värdens standardrutt. Båda är försvarbara; en värdrutt med en gissad gateway är det inte. Skriv ner vilken du valde, och registrera peer-adressen som måste överleva.