Mengapa RDP Membeku Apabila Komputer Jauh Bersambung ke VPN

Anda berada di dalam tetingkap RDP, desktop terpapar di skrin, dan anda menekan Connect dalam klien VPN yang berjalan pada mesin jauh itu. Beberapa detik kemudian tetingkap membeku dan kemudian tertutup. Terowong naik, itulah yang akan dicatat oleh log VPN, dan itulah fakta paling tidak berguna dalam seluruh insiden ini. Sesi mati kerana mesin yang anda bercakap dengannya mengubah cara ia menjawab anda, jadi teliti laluan balik sebelum menyentuh terowong.

Catat titik akhir yang benar-benar digunakan oleh sesi anda

Alamat yang ditaip dalam klien RDP anda belum tentu alamat yang dijawab oleh komputer jauh. NAT, RD Gateway atau pengimbang beban di hadapan hos boleh menulis semula alamat itu, dan laluan balik ditentukan oleh alamat sumber yang dilihat oleh mesin jauh pada sambungan yang telah terbentuk. Tersilap di sini akan membuat anda mencari laluan yang tidak pernah terlibat.

Pada komputer jauh, sebelum VPN disambungkan, senaraikan sesi yang terbentuk dan baca alamat peer daripada jadual. Kemudian catatkannya di suatu tempat di luar mesin itu, kerana anda tidak akan dapat membacanya selepas sesi terputus.

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

Anggap alamat itu sebagai perkara yang mesti kekal boleh dicapai. Jika ia alamat peribadi pada VLAN pengurusan, terowong mesti membiarkan laluan itu. Jika ia alamat awam, balasan mesti keluar melalui antara muka yang sama yang membawa permintaan masuk.

Baca laluan yang menjawab titik akhir itu

Windows memilih antara muka bagi setiap destinasi, dan Find-NetRoute menunjukkan keputusan yang akan diambilnya sekarang. Jalankannya pada alamat peer sebelum menyambung, kemudian sekali lagi dengan terowong naik, dan bandingkan indeks antara muka serta hop seterusnya dalam kedua-dua jawapan. Perubahan antara muka ialah seluruh pepijat dalam satu baris keluaran.

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

Profil terowong penuh memasang laluan lalai melalui terowong, seperti yang dijelaskan oleh panduan penghalaan VPN Windows, jadi setiap balasan kini keluar melalui VPN dan bergantung pada sama ada pihak bertentangan menghala balik ke klien anda. Profil terowong terpisah lebih selamat secara lalai tetapi tidak kebal, kerana laluan khusus yang meliputi alamat peer masih boleh mengalahkan laluan lalai fizikal. Dalam apa jua keadaan soalnya sama: selepas terowong naik, adakah alamat peer masih diselesaikan ke antara muka yang membawa sesi masuk?

Jika tidak, pembetulan terletak pada profil atau pada laluan pengecualian eksplisit yang diluluskan oleh pemilik dasar VPN. Menyunting jadual penghalaan dengan tangan pada hos pengeluaran semasa insiden ialah cara penyelesaian sementara menjadi konfigurasi tanpa dokumentasi.

Perhatikan perubahan profil firewall

Antara muka baharu dikelaskan apabila ia muncul, dan klasifikasi itu menentukan profil firewall mana yang menilai trafiknya. Penyesuai terowong yang jatuh ke dalam kategori Public boleh menghentikan RDP masuk secara senyap walaupun jadual penghalaan kelihatan sempurna. Ini mod kegagalan kedua, dan ia menghasilkan simptom berbeza: laluan betul, paket tiba, dan hos menolak sambungan.

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

Bandingkan profil yang terikat pada antara muka terowong dengan profil yang menjadi sasaran peraturan Remote Desktop. Peraturan yang didayakan hanya untuk Domain dan Private tidak melakukan apa-apa bagi antara muka yang dikelaskan Public, dan tiada pembetulan laluan mengubahnya. Sesetengah klien VPN juga mengehadkan akses ke subranet tempatan secara reka bentuk, yang menghasilkan bentuk kegagalan sama daripada kawalan lain.

Uji peralihan itu dari tempat yang anda boleh pulihkan

Lakukan seluruh urutan dari konsol luar jalur atau laluan pengurusan kedua, dalam susunan ini: sahkan sesi sedia ada, sambungkan VPN, buka sesi baharu, kemudian putuskan VPN dan buka satu lagi. Setiap langkah menguji peralihan berbeza, dan langkah pertama yang gagal memberitahu anda kawalan mana yang bertanggungjawab.

Jadualkan pengunduran sebelum bermula, contohnya tugas berjadual yang menjalankan rasdial "Work VPN" /disconnect selepas selang tertentu. Itu menukar sesi yang hilang menjadi gangguan lima minit dan bukannya lawatan ke lokasi, dan itulah insurans paling murah dalam seluruh prosedur.

Masuk semula apabila sesi sudah hilang

Jika hos sudah tidak dapat dicapai, berhenti mencuba sambungan RDP baharu daripada klien yang sama dan gunakan saluran pemulihan yang sudah ada pada persekitaran: RD Gateway, konsol hypervisor atau antara muka pengurusan luar jalur. Minta orang yang mempunyai akses konsol menjalankan arahan yang sama Find-NetRoute dan Get-NetConnectionProfile, supaya bukti bertahan selepas pemulihan.

Kemudian putuskan susunan kekal dan bukannya yang terpantas. Sama ada laluan pengurusan dipelihara secara eksplisit oleh profil VPN, atau pengurusan berpindah ke saluran yang tidak bergantung pada laluan lalai hos. Kedua-duanya boleh dipertahankan; laluan hos dengan gerbang tekaan tidak. Tulis yang mana anda pilih, dan catat alamat peer yang perlu bertahan.