Mengapa RDP Membeku Saat Komputer Jarak Jauh Terhubung ke VPN

Anda berada di dalam jendela RDP, desktop tampil di layar, dan Anda menekan Connect di klien VPN yang berjalan di mesin jarak jauh itu. Beberapa detik kemudian jendela membeku lalu tertutup. Terowongan berhasil naik, itulah yang akan dicatat log VPN, dan itu fakta paling tidak berguna dalam seluruh insiden ini. Sesi mati karena mesin yang Anda ajak bicara mengubah cara ia menjawab Anda, jadi telusuri jalur balik sebelum menyentuh terowongan.

Catat endpoint yang benar-benar dipakai sesi Anda

Alamat yang diketik di klien RDP Anda belum tentu alamat yang dijawab komputer jarak jauh. NAT, RD Gateway, atau penyeimbang beban di depan host bisa menulis ulang alamat itu, dan jalur balik ditentukan oleh alamat sumber yang dilihat mesin jarak jauh pada koneksi yang sudah terbentuk. Salah di sini akan membuat Anda mencari rute yang tidak pernah terlibat.

Di komputer jarak jauh, sebelum VPN terhubung, daftarkan sesi yang terbentuk dan baca alamat peer dari tabel. Lalu catat di suatu tempat di luar mesin itu, karena Anda tidak akan bisa membacanya setelah sesi putus.

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

Perlakukan alamat itu sebagai hal yang harus tetap bisa dijangkau. Jika itu alamat privat di VLAN manajemen, terowongan harus membiarkan jalur itu. Jika itu alamat publik, balasannya harus keluar lewat antarmuka yang sama yang membawa permintaan masuk.

Baca rute yang menjawab endpoint tersebut

Windows memilih antarmuka untuk setiap tujuan, dan Find-NetRoute menunjukkan keputusan yang akan diambilnya sekarang. Jalankan terhadap alamat peer sebelum menghubungkan, lalu lagi dengan terowongan naik, dan bandingkan indeks antarmuka serta hop berikutnya pada kedua jawaban. Perubahan antarmuka adalah seluruh bug 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 terowongan penuh memasang rute default melalui terowongan, seperti yang dijelaskan panduan perutean VPN Windows, jadi setiap balasan kini keluar lewat VPN dan bergantung pada sisi seberang merutekan balik ke klien Anda. Profil terowongan terpisah lebih aman secara default tetapi tidak kebal, karena rute spesifik yang mencakup alamat peer masih bisa mengalahkan rute default fisik. Bagaimanapun pertanyaannya sama: setelah terowongan naik, apakah alamat peer masih mengarah ke antarmuka yang membawa sesi masuk?

Jika tidak, perbaikannya ada di profil atau di rute pengecualian eksplisit yang disetujui pemilik kebijakan VPN. Mengedit tabel perutean dengan tangan di host produksi saat insiden adalah cara sebuah solusi sementara menjadi konfigurasi tanpa dokumentasi.

Amati perubahan profil firewall

Antarmuka baru diklasifikasikan saat muncul, dan klasifikasi itu menentukan profil firewall mana yang dipakai menilai trafiknya. Adaptor terowongan yang masuk kategori Public bisa diam-diam menghentikan RDP masuk meski tabel perutean tampak sempurna. Ini mode kegagalan kedua, dan gejalanya berbeda: rutenya benar, paketnya datang, dan host menolak koneksi.

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

Bandingkan profil yang terpasang pada antarmuka terowongan dengan profil yang menjadi sasaran aturan Remote Desktop. Aturan yang hanya diaktifkan untuk Domain dan Private tidak melakukan apa pun bagi antarmuka yang diklasifikasikan Public, dan tidak ada koreksi rute yang mengubahnya. Sebagian klien VPN juga membatasi akses ke subnet lokal secara desain, yang menghasilkan bentuk kegagalan sama dari kendali lain.

Uji transisinya dari tempat yang bisa Anda pulihkan

Lakukan seluruh urutan dari konsol out-of-band atau jalur manajemen kedua, dengan urutan ini: pastikan sesi yang ada, hubungkan VPN, buka sesi baru, lalu putuskan VPN dan buka satu lagi. Setiap langkah menguji transisi berbeda, dan langkah pertama yang gagal memberi tahu Anda kendali mana yang bertanggung jawab.

Jadwalkan rollback sebelum mulai, misalnya tugas terjadwal yang menjalankan rasdial "Work VPN" /disconnect setelah selang waktu tertentu. Itu mengubah sesi yang hilang menjadi gangguan lima menit alih-alih kunjungan ke lokasi, dan itulah asuransi termurah dalam seluruh prosedur.

Masuk kembali saat sesinya sudah hilang

Jika host sudah tidak terjangkau, berhenti mencoba koneksi RDP baru dari klien yang sama dan gunakan kanal pemulihan yang sudah dimiliki lingkungan: RD Gateway, konsol hypervisor, atau antarmuka manajemen out-of-band. Minta orang yang punya akses konsol menjalankan perintah yang sama Find-NetRoute dan Get-NetConnectionProfile, agar buktinya bertahan setelah pemulihan.

Lalu putuskan pengaturan permanen, bukan yang tercepat. Entah jalur manajemen dipertahankan secara eksplisit oleh profil VPN, atau manajemen pindah ke kanal yang tidak bergantung pada rute default host. Keduanya bisa dipertahankan; rute host dengan gateway tebakan tidak. Tuliskan mana yang Anda pilih, dan catat alamat peer yang harus bertahan.