RDP Shortpath menetapkan transportasi berbasis UDP langsung antara aplikasi Windows perangkat lokal atau aplikasi Desktop Jauh pada platform dan host sesi yang didukung di Azure Virtual Desktop.
Secara default, Protokol Desktop Jauh (RDP) mencoba membuat sesi jarak jauh menggunakan UDP dan menggunakan transportasi koneksi terbalik berbasis TCP sebagai mekanisme koneksi fallback. Transportasi berbasis UDP menawarkan keandalan koneksi yang lebih baik dan latensi yang lebih konsisten. Transportasi reverse connect berbasis TCP memberikan kompatibilitas terbaik dengan berbagai konfigurasi jaringan dan memiliki tingkat keberhasilan yang tinggi untuk membuat koneksi RDP.
RDP Shortpath dapat digunakan dengan dua cara:
Jaringan terkelola, di mana konektivitas langsung dibuat antara klien dan host sesi saat menggunakan koneksi privat, seperti jaringan privat Maya (VPN). Koneksi menggunakan jaringan terkelola dibuat dengan salah satu cara berikut:
Koneksi UDP langsung antara perangkat klien dan host sesi, di mana Anda perlu mengaktifkan pendengar RDP Shortpath dan mengizinkan port masuk pada setiap host sesi untuk menerima koneksi.
Koneksi UDP langsung antara perangkat klien dan host sesi, menggunakan protokol Simple Traversal Underneath NAT (STUN) antara klien dan host sesi. Port masuk pada host sesi tidak diharuskan untuk diizinkan.
Jaringan publik, tempat konektivitas langsung dibuat antara klien dan host sesi saat menggunakan koneksi publik. Ada dua jenis koneksi saat menggunakan koneksi publik, yang tercantum di sini dalam urutan preferensi:
Koneksi UDP langsung menggunakan protokol Simple Traversal Underneath NAT (STUN) antara klien dan host sesi.
Koneksi UDP tidak langsung menggunakan protokol Traversal Using Relay NAT (TURN) dengan relai antara klien dan host sesi.
Transportasi yang digunakan untuk RDP Shortpath didasarkan pada Universal Rate Control Protocol (URCP). URCP meningkatkan UDP dengan pemantauan aktif pada kondisi jaringan dan memberikan pemanfaatan tautan yang adil dan lengkap. URCP beroperasi pada tingkat penundaan dan kehilangan yang rendah sesuai kebutuhan.
Penting
RDP Shortpath untuk jaringan publik dengan TURN hanya tersedia di cloud publik Azure.
Manfaat utama
Menggunakan RDP Shortpath memiliki keuntungan utama sebagai berikut:
Menggunakan URCP untuk meningkatkan UDP mencapai performa terbaik dengan mempelajari parameter jaringan secara dinamis dan menyediakan protokol dengan mekanisme kontrol kecepatan.
Penghapusan titik relai tambahan mengurangi waktu komunikasi dua arah, yang meningkatkan keandalan koneksi dan pengalaman pengguna dengan aplikasi dan metode input yang sensitif terhadap latensi.
Selain itu, untuk jaringan terkelola:
RDP Shortpath memberikan dukungan untuk mengonfigurasi prioritas Kualitas Layanan (QoS) untuk koneksi RDP melalui tanda Titik Kode Layanan Berbeda (DSCP).
Transportasi RDP Shortpath memungkinkan pembatasan lalu lintas jaringan keluar dengan menentukan kecepatan pembatasan untuk setiap sesi.
Cara kerja RDP Shortpath
Untuk mempelajari cara kerja RDP Shortpath untuk jaringan terkelola dan jaringan publik, pilih setiap tab berikut.
Anda dapat mencapai konektivitas garis pandang langsung yang diperlukan untuk menggunakan RDP Shortpath dengan jaringan terkelola menggunakan metode berikut.
VPN Situs-ke-situs atau Titik-ke-situs (IPsec), seperti Azure VPN Gateway
Memiliki konektivitas garis pandang langsung berarti bahwa klien dapat tersambung langsung ke host sesi tanpa diblokir oleh firewall.
Catatan
Jika Anda menggunakan jenis VPN lain untuk tersambung ke Azure, sebaiknya gunakan VPN berbasis UDP. Sementara sebagian besar solusi VPN berbasis TCP mendukung UDP berlapis, mereka menambahkan overhead bawaan dari kontrol kemacetan TCP, yang memperlambat performa RDP.
Untuk menggunakan RDP Shortpath untuk jaringan terkelola, Anda harus mengaktifkan pendengar UDP di host sesi Anda. Secara default, port 3390 digunakan, meskipun Anda dapat menggunakan port yang berbeda.
Diagram berikut memberikan gambaran umum tingkat tinggi tentang koneksi jaringan saat menggunakan RDP Shortpath untuk jaringan terkelola dan host sesi yang bergabung ke domain Direktori Aktif.
Urutan koneksi
Semua koneksi dimulai dengan membuat transportasi koneksi terbalik berbasis TCP melalui Azure Virtual Desktop Gateway. Kemudian, klien dan host sesi membuat transportasi RDP awal, dan mulai bertukar kemampuan mereka. Kemampuan ini dinegosiasikan menggunakan proses berikut:
Host sesi mengirimkan daftar alamat IPv4 dan IPv6 ke klien.
Klien memulai alur latar belakang untuk membuat transportasi berbasis UDP paralel secara langsung ke salah satu alamat IP host sesi.
Saat klien memeriksa alamat IP yang disediakan, klien melanjutkan pembentukan koneksi awal melalui transportasi koneksi terbalik untuk memastikan tidak ada penundaan dalam koneksi pengguna.
Jika klien memiliki koneksi langsung ke host sesi, klien membuat koneksi aman menggunakan TLS melalui UDP yang andal.
Setelah membuat transportasi RDP Shortpath, semua Dynamic Virtual Channels (DVC), termasuk grafik jarak jauh, input, dan pengalihan perangkat, dipindahkan ke transportasi baru. Namun, jika firewall atau topologi jaringan mencegah klien membuat konektivitas UDP langsung, RDP melanjutkan dengan transportasi koneksi terbalik.
Jika pengguna Anda memiliki RDP Shortpath untuk jaringan terkelola dan jaringan publik yang tersedia untuk mereka, maka algoritma pertama yang ditemukan akan digunakan. Pengguna akan menggunakan koneksi mana pun yang akan dibuat terlebih dahulu untuk sesi tersebut.
Untuk memberikan peluang terbaik agar koneksi UDP berhasil saat menggunakan koneksi publik, ada jenis koneksi langsung dan tidak langsung :
Koneksi langsung: STUN digunakan untuk membuat koneksi UDP langsung antara klien dan host sesi. Untuk membuat koneksi ini, klien dan host sesi harus dapat terhubung satu sama lain melalui alamat IP publik dan port yang dinegosiasikan. Namun, sebagian besar klien tidak tahu alamat IP publik mereka sendiri saat mereka duduk di belakang perangkat gateway Network Address Translation (NAT ). STUN adalah protokol untuk penemuan sendiri alamat IP publik dari belakang perangkat gateway NAT dan klien untuk menentukan alamat IP publiknya sendiri.
Agar klien dapat menggunakan STUN, jaringannya harus mengizinkan lalu lintas UDP. Dengan asumsi klien dan host sesi dapat merutekan ke alamat IP dan port lain yang ditemukan secara langsung, komunikasi dibuat dengan UDP langsung melalui protokol WebSocket. Jika firewall atau perangkat jaringan lain memblokir koneksi langsung, koneksi UDP tidak langsung akan dicoba.
Koneksi tidak langsung: TURN digunakan untuk membuat koneksi tidak langsung, menyampaikan lalu lintas melalui server perantara antara klien dan host sesi saat koneksi langsung tidak dimungkinkan. TURN adalah perpanjangan dari STUN. Menggunakan TURN berarti alamat IP publik dan port diketahui terlebih dahulu, yang dapat diizinkan melalui firewall dan perangkat jaringan lainnya.
TURN biasanya mengotorisasi akses ke server melalui nama pengguna/kata sandi dan mode operasi pilihannya adalah menggunakan soket UDP. Jika firewall atau perangkat jaringan lain memblokir lalu lintas UDP, koneksi akan kembali ke transportasi koneksi terbalik berbasis TCP.
Ketika koneksi sedang dibuat, Interactive Connectivity Establishment (ICE) mengoordinasikan manajemen STUN dan TURN untuk mengoptimalkan kemungkinan koneksi yang dibuat, dan memastikan bahwa prioritas diberikan kepada protokol komunikasi jaringan pilihan.
Setiap sesi RDP menggunakan port UDP yang ditetapkan secara dinamis dari rentang port sementara (49152 hingga 65535 secara default) yang menerima lalu lintas RDP Shortpath. Port 65330 diabaikan dari rentang ini karena dicadangkan untuk digunakan secara internal oleh Azure. Anda juga dapat menggunakan rentang port yang lebih kecil dan dapat diprediksi. Untuk informasi selengkapnya, lihat Membatasi rentang port yang digunakan oleh klien untuk jaringan publik.
Tip
RDP Shortpath untuk jaringan publik akan bekerja secara otomatis tanpa konfigurasi tambahan, menyediakan jaringan dan firewall memungkinkan lalu lintas melalui dan pengaturan transportasi RDP di sistem operasi Windows untuk host sesi dan klien menggunakan nilai default mereka.
Diagram berikut memberikan gambaran umum tingkat tinggi tentang koneksi jaringan saat menggunakan RDP Shortpath untuk jaringan publik tempat host sesi bergabung ke ID Microsoft Entra.
NAT dan firewall
Sebagian besar klien Azure Virtual Desktop berjalan di komputer di jaringan privat. Akses internet disediakan melalui perangkat gateway Network Address Translation (NAT). Oleh karena itu, gateway NAT mengubah semua permintaan jaringan dari jaringan privat dan ditujukan ke Internet. Pengubahan tersebut ditujukan untuk berbagi satu alamat IP publik di semua komputer di jaringan privat.
Karena modifikasi paket IP, penerima lalu lintas akan melihat alamat IP publik gateway NAT, bukan pengirim aktual. Ketika kembali ke gateway NAT, lalu lintas akan berhati-hati meneruskannya ke penerima tujuan tanpa sepengetahuan pengirim. Dalam kebanyakan skenario, perangkat yang tersembunyi di balik NAT seperti itu tidak menyadari bahwa penerjemahan sedang dilakukan dan tidak mengetahui alamat jaringan NAT gateway.
NAT berlaku untuk Azure Virtual Networks tempat semua host sesi berada. Saat host sesi mencoba menjangkau alamat jaringan di Internet, NAT Gateway (baik milik Anda sendiri atau default yang disediakan oleh Azure), atau Azure Load Balancer melakukan penerjemahan alamat. Untuk informasi selengkapnya tentang berbagai jenis Terjemahan Alamat Jaringan Sumber, lihat Menggunakan Terjemahan Alamat Jaringan Sumber (SNAT) untuk koneksi keluar.
Sebagian besar jaringan biasanya mencakup firewall yang memeriksa lalu lintas dan memblokirnya berdasarkan aturan. Sebagian besar pelanggan mengonfigurasikan firewall mereka untuk mencegah koneksi masuk (yaitu, paket yang tidak diminta dari Internet yang dikirim tanpa permintaan). Firewall menggunakan teknik yang berbeda untuk melacak aliran data untuk membedakan antara lalu lintas yang diminta dan yang tidak diminta. Dalam konteks TCP, firewall tersebut melacak paket SYN dan ACK, dan prosesnya mudah. Firewall UDP biasanya menggunakan heuristik berdasarkan alamat paket untuk mengaitkan lalu lintas dengan alur UDP dan mengizinkan atau memblokirnya.
Ada banyak implementasi NAT berbeda yang tersedia. Dalam sebagian besar kasus, gateway NAT dan firewall adalah fungsi dari perangkat fisik atau virtual yang sama.
Urutan koneksi
Semua koneksi dimulai dengan membuat transportasi koneksi terbalik berbasis TCP melalui Azure Virtual Desktop Gateway. Kemudian, klien dan host sesi membuat transportasi RDP awal, dan mulai bertukar kemampuan mereka. Jika RDP Shortpath untuk jaringan publik diaktifkan pada host sesi, host sesi kemudian memulai proses yang disebut pengumpulan kandidat:
Host sesi menghitung semua antarmuka jaringan yang ditetapkan ke host sesi, termasuk antarmuka virtual seperti VPN dan Teredo.
Layanan Windows Layanan Desktop Jauh (TermService) mengalokasikan soket UDP pada setiap antarmuka dan menyimpan pasangan IP:Port dalam tabel kandidat sebagai kandidat lokal.
Layanan untuk Layanan Desktop Jauh menggunakan setiap soket UDP yang dialokasikan pada langkah sebelumnya untuk mencoba menjangkau Server STUN Azure Virtual Desktop di internet publik. Komunikasi dilakukan dengan mengirimkan paket UDP kecil ke port 3478.
Jika paket mencapai server STUN, server STUN merespons dengan IP publik dan port. Informasi ini disimpan dalam tabel kandidat sebagai kandidat refleksif.
Setelah host sesi mengumpulkan semua kandidat, host sesi menggunakan transportasi koneksi terbalik yang telah ditetapkan untuk meneruskan daftar kandidat ke klien.
Ketika klien menerima daftar kandidat dari host sesi, klien juga melakukan pengumpulan kandidat di sisinya. Lalu, klien tersebut mengirimkan daftar kandidatnya ke host sesi.
Setelah host sesi dan klien bertukar daftar kandidat mereka, kedua belah pihak mencoba untuk terhubung satu sama lain menggunakan semua kandidat yang dikumpulkan. Upaya koneksi ini serentak dilakukan di kedua sisi. Banyak NAT gateway dikonfigurasi untuk mengizinkan lalu lintas masuk ke soket segera setelah transfer data keluar menginisialisasinya. Perilaku gateway NAT ini adalah alasan pentingnya koneksi simultan. Jika STUN gagal karena diblokir, upaya koneksi tidak langsung dilakukan menggunakan TURN.
Setelah pertukaran paket awal, klien dan host sesi dapat membuat satu atau banyak aliran data. Dari aliran data ini, RDP memilih jalur jaringan tercepat. Klien kemudian membuat koneksi aman menggunakan TLS melalui UDP yang andal dengan host sesi dan memulai transportasi RDP Shortpath.
Setelah RDP membuat transportasi RDP Shortpath, semua Dynamic Virtual Channels (DVC), termasuk grafik jarak jauh, input, dan pengalihan perangkat pindah ke transportasi baru.
Jika pengguna Anda memiliki RDP Shortpath untuk jaringan terkelola dan jaringan publik yang tersedia untuk mereka, maka algoritma pertama yang ditemukan akan digunakan, yang berarti bahwa pengguna akan menggunakan koneksi mana pun yang akan dibuat terlebih dahulu untuk sesi tersebut. Untuk informasi selengkapnya, lihat contoh skenario 4.
Penting
Saat menggunakan transportasi berbasis TCP, lalu lintas keluar dari host sesi ke klien melalui Azure Virtual Desktop Gateway. Dengan RDP Shortpath untuk jaringan publik yang menggunakan STUN, lalu lintas keluar dibuat langsung antara host sesi dan klien melalui internet. Ini menghapus hop yang meningkatkan latensi dan pengalaman pengguna akhir. Namun, karena perubahan aliran data antara host sesi dan klien di mana Gateway tidak lagi digunakan, akan ada biaya jaringan egress Azure standar yang ditagih sebagai tambahan per langganan untuk bandwidth internet yang digunakan. Untuk mempelajari lebih lanjut tentang memperkirakan bandwidth yang digunakan oleh RDP, lihat Persyaratan bandwidth RDP.
Konfigurasi jaringan
Untuk mendukung RDP Shortpath untuk jaringan publik, Anda biasanya tidak memerlukan konfigurasi tertentu. Host sesi dan klien akan secara otomatis menemukan aliran data langsung jika memungkinkan dalam konfigurasi jaringan Anda. Namun, setiap lingkungan itu unik, dan beberapa konfigurasi jaringan dapat berdampak negatif pada tingkat keberhasilan koneksi langsung. Ikuti rekomendasi untuk meningkatkan probabilitas aliran data langsung.
Karena RDP Shortpath menggunakan UDP untuk membuat aliran data, jika firewall di jaringan Anda memblokir lalu lintas UDP, RDP Shortpath akan gagal dan koneksi akan kembali ke transportasi koneksi balik berbasis TCP. Azure Virtual Desktop menggunakan server STUN yang disediakan oleh Azure Communication Services dan Microsoft Teams. Berdasarkan sifat fitur, konektivitas keluar dari host sesi ke klien diperlukan. Sayangnya, Anda tidak dapat memprediksi lokasi pengguna Anda berada dalam sebagian besar kasus. Oleh karena itu, sebaiknya izinkan konektivitas UDP keluar dari host sesi Anda ke internet. Untuk mengurangi jumlah port yang diperlukan, Anda dapat membatasi rentang port yang digunakan oleh klien untuk alur UDP. Gunakan tabel berikut untuk referensi saat mengonfigurasi firewall untuk RDP Shortpath.
Jika lingkungan Anda menggunakan NAT Simetris, yang merupakan pemetaan SATU IP sumber privat:Port ke IP:Port tujuan publik yang unik, maka Anda dapat menggunakan koneksi tidak langsung dengan TURN. Ini akan terjadi jika Anda menggunakan Azure Firewall dan Azure NAT Gateway. Untuk informasi selengkapnya tentang NAT dengan jaringan virtual Azure, lihat Penerjemahan Alamat Jaringan Sumber dengan jaringan virtual.
Di mana pengguna memiliki RDP Shortpath untuk jaringan terkelola dan jaringan publik tersedia untuk mereka, maka algoritma pertama yang ditemukan akan digunakan. Pengguna akan menggunakan koneksi mana pun yang akan dibuat terlebih dahulu untuk sesi tersebut. Untuk informasi selengkapnya, lihat Contoh skenario.
Ketersediaan TURN
TURN tersedia di wilayah Azure berikut:
Australia Tenggara
India Tengah
AS Timur
AS Timur 2
Prancis Tengah
Jepang Barat
Eropa Utara
US Tengah Selatan
Asia Tenggara
UK Selatan
UK Barat
Eropa Barat
US Barat
US Barat 2
Jaringan virtual host sesi
Nama
Sumber
Port sumber
Tujuan
Port Tujuan
Protokol
Perbuatan
Titik Akhir Server RDP Shortpath
Subnet mesin virtual
Apa pun
Apa pun
1024-65535 (default 49152-65535)
UDP
Izinkan
STUN/TURN UDP
Subnet mesin virtual
Mana pun
20.202.0.0/16
3478
UDP
Izinkan
STUN/TURN TCP
Subnet mesin virtual
Mana pun
20.202.0.0/16
443
TCP
Izinkan
Jaringan klien
Nama
Sumber
Port sumber
Tujuan
Port Tujuan
Protokol
Perbuatan
Titik Akhir Server RDP Shortpath
Jaringan klien
Mana pun
Alamat IP publik yang ditetapkan ke NAT Gateway atau Azure Firewall (disediakan oleh titik akhir STUN)
1024-65535 (default 49152-65535)
UDP
Izinkan
STUN/TURN UDP
Jaringan klien
Mana pun
20.202.0.0/16
3478
UDP
Izinkan
STUN/TURN TCP
Jaringan klien
Mana pun
20.202.0.0/16
443
TCP
Izinkan
Dukungan Teredo
Meskipun tidak diperlukan untuk RDP Shortpath, Teredo menambahkan kandidat traversal NAT tambahan dan meningkatkan peluang keberhasilan koneksi RDP Shortpath di jaringan khusus IPv4. Untuk mempelajari cara mengaktifkan Teredo pada host sesi dan klien, lihat Mengaktifkan dukungan Teredo.
Dukungan UPnP
Untuk meningkatkan peluang koneksi langsung, di sisi klien Desktop Jauh, RDP Shortpath dapat menggunakan UPnP untuk mengonfigurasikan pemetaan port pada router NAT. UPnP adalah teknologi standar yang digunakan oleh berbagai aplikasi, seperti Xbox, Optimalisasi Pengiriman, dan Teredo. UPnP umumnya tersedia pada router yang biasanya ditemukan di jaringan rumah. UPnP diaktifkan secara default pada sebagian besar router rumah dan titik akses, tetapi sering dinonaktifkan di jaringan perusahaan.
Rekomendasi umum
Berikut adalah beberapa rekomendasi umum saat menggunakan RDP Shortpath untuk jaringan publik:
Hindari menggunakan konfigurasi penerowongan paksa jika pengguna Anda mengakses Azure Virtual Desktop melalui Internet.
Pastikan Anda tidak menggunakan konfigurasi NAT ganda atau Carrier-Grade-NAT (CGN).
Rekomendasikan kepada pengguna Anda bahwa mereka tidak menonaktifkan UPnP di router rumah mereka.
Hindari menggunakan Layanan inspeksi paket cloud.
Hindari menggunakan solusi VPN berbasis TCP.
Mengaktifkan konektivitas IPv6 atau Teredo.
Keamanan koneksi
RDP Shortpath memperluas kemampuan multi-transportasi RDP. Ini tidak menggantikan transportasi sambungan terbalik, tetapi melengkapinya. Broker sesi awal dikelola melalui layanan Azure Virtual Desktop dan transportasi koneksi terbalik. Semua upaya koneksi diabaikan kecuali jika cocok dengan sesi koneksi terbalik terlebih dahulu. RDP Shortpath dibuat setelah autentikasi, dan jika berhasil dibuat, transportasi koneksi terbalik akan dihilangkan dan semua alur lalu lintas melalui Shortpath RDP.
RDP Shortpath menggunakan koneksi aman menggunakan TLS melalui UDP yang andal antara klien dan host sesi menggunakan sertifikat host sesi. Secara default, sertifikat yang digunakan untuk enkripsi RDP dibuat sendiri oleh sistem operasi selama penyebaran. Anda juga dapat menyebarkan sertifikat yang dikelola secara terpusat yang dikeluarkan oleh otoritas sertifikasi perusahaan. Untuk informasi selengkapnya tentang konfigurasi sertifikat, lihat Konfigurasi sertifikat pendengar Desktop Jauh.
Catatan
Keamanan yang ditawarkan oleh RDP Shortpath sama dengan yang ditawarkan oleh transportasi reverse connect TCP.
Skenario contoh
Berikut adalah beberapa contoh skenario untuk menunjukkan bagaimana koneksi dievaluasi untuk memutuskan apakah RDP Shortpath digunakan di berbagai topologi jaringan.
Skenario 1
Koneksi UDP hanya dapat dibuat antara perangkat klien dan host sesi melalui jaringan publik (internet). Koneksi langsung, seperti VPN, tidak tersedia. UDP diizinkan melalui firewall atau perangkat NAT.
Skenario 2
Firewall atau perangkat NAT memblokir koneksi UDP langsung, tetapi koneksi UDP tidak langsung dapat disampaikan menggunakan TURN antara perangkat klien dan host sesi melalui jaringan publik (internet). Koneksi langsung lainnya, seperti VPN, tidak tersedia.
Skenario 3
Koneksi UDP dapat dibuat antara perangkat klien dan host sesi melalui jaringan publik atau melalui koneksi VPN langsung, tetapi RDP Shortpath untuk jaringan terkelola tidak diaktifkan. Ketika klien memulai koneksi, protokol ICE/STUN dapat melihat beberapa rute dan akan mengevaluasi setiap rute dan memilih rute dengan latensi terendah.
Dalam contoh ini, koneksi UDP menggunakan RDP Shortpath untuk jaringan publik melalui koneksi VPN langsung akan dibuat karena memiliki latensi terendah, seperti yang ditunjukkan oleh garis hijau.
Skenario 4
RDP Shortpath untuk jaringan publik dan jaringan terkelola diaktifkan. Koneksi UDP dapat dibuat antara perangkat klien dan host sesi melalui jaringan publik atau melalui koneksi VPN langsung. Ketika klien memulai koneksi, ada upaya simultan untuk terhubung menggunakan RDP Shortpath untuk jaringan terkelola melalui port 3390 (secara default) dan RDP Shortpath untuk jaringan publik melalui protokol ICE/STUN. Algoritma pertama yang ditemukan akan digunakan dan pengguna akan menggunakan koneksi mana pun yang akan dibuat terlebih dahulu untuk sesi tersebut.
Karena melalui jaringan publik memiliki lebih banyak langkah, misalnya perangkat NAT, load balancer, atau server STUN, kemungkinan algoritma yang ditemukan pertama kali akan memilih koneksi menggunakan RDP Shortpath untuk jaringan terkelola dan dibuat terlebih dahulu.
Skenario 5
Koneksi UDP dapat dibuat antara perangkat klien dan host sesi melalui jaringan publik atau melalui koneksi VPN langsung, tetapi RDP Shortpath untuk jaringan terkelola tidak diaktifkan. Untuk mencegah ICE/STUN menggunakan rute tertentu, admin dapat memblokir salah satu rute untuk lalu lintas UDP. Memblokir rute akan memastikan jalur yang tersisa selalu digunakan.
Dalam contoh ini, UDP diblokir pada koneksi VPN langsung dan protokol ICE/STUN membuat koneksi melalui jaringan publik.
Skenario 6
Baik RDP Shortpath untuk jaringan publik dan jaringan terkelola dikonfigurasi, namun koneksi UDP tidak dapat dibuat menggunakan koneksi VPN langsung. Firewall atau perangkat NAT juga memblokir koneksi UDP langsung menggunakan jaringan publik (internet), tetapi koneksi UDP tidak langsung dapat disampaikan menggunakan TURN antara perangkat klien dan host sesi melalui jaringan publik (internet).
Skenario 7
Baik RDP Shortpath untuk jaringan publik dan jaringan terkelola dikonfigurasi, namun koneksi UDP tidak dapat dibuat. Dalam hal ini, RDP Shortpath akan gagal dan koneksi akan kembali ke transportasi koneksi terbalik berbasis TCP.
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.