NAT traversal dijelaskan: bagaimana remote desktop P2P menembus router Anda.

Anda punya satu IP publik dan belasan perangkat di balik router. iPad Anda memakai seluler, tiga jaringan jauhnya. Entah bagaimana, aplikasi remote desktop membuka koneksi langsung dari satu ke yang lain dalam waktu kurang dari satu detik — biasanya tanpa relay di tengah. Beginilah sihir itu bekerja: ICE, STUN, TURN, hole punching, dan kenyataan pahit tentang NAT simetris.

Mengapa ini penting

Bayangkan Selasa pagi. Mac mini Anda di rumah di balik router dengan satu alamat IPv4 publik. iPad Anda di kereta, di jaringan seluler operator dengan lapisan translasi alamatnya sendiri. Setidaknya dua NAT berada di antara kedua perangkat, mungkin tiga. Tak satu pun mesin bisa dijangkau dari Internet luar secara default.

Namun Anda membuka Remio di iPad, mengetuk Mac, dan sedetik kemudian Anda sudah melihat desktop Anda. Video dan input mengalir langsung antara kedua perangkat — tanpa relay cloud, tanpa proxy di tengah yang meng-encode ulang layar Anda.

Teknik yang memungkinkan ini punya nama — NAT traversal — dan keluarga protokol yang terdefinisi dengan baik di baliknya: STUN, TURN, dan ICE. Ini protokol yang sama yang dipakai WebRTC untuk panggilan video di browser, dan inilah sebabnya remote desktop P2P modern mana pun bisa menghindari memaksa frame layar Anda melewati pusat data pihak ketiga. Artikel ini menguraikan fungsi masing-masing, mengapa ia ada, dan bagaimana semuanya bergabung menemukan jalur berlatensi terendah antara dua perangkat yang bersembunyi di balik router.

Masalah NAT dalam 60 detik

Internet dirancang agar setiap perangkat punya alamat publiknya sendiri yang bisa dirutekan. Ada sekitar 4,3 miliar alamat IPv4 di seluruh ruangnya — melimpah pada 1981, jelas tidak cukup pada akhir 1990-an.

Solusi sementaranya adalah Network Address Translation. Router Anda mendapat satu alamat IPv4 publik dari ISP. Di dalam rumah, setiap perangkat mendapat alamat privat dari rentang yang dicadangkan (biasanya 192.168.x.x atau 10.x.x.x). Ketika laptop Anda mengirim paket keluar, router menulis ulang alamat sumber menjadi IP publiknya sendiri, mengingat pemetaannya, lalu meneruskan. Ketika balasan tiba, router mencari pemetaan itu dan menulis ulang tujuan kembali ke laptop Anda.

Inilah sebabnya koneksi masuk tidak berfungsi secara default. Dari luar, laptop Anda tidak punya alamat; hanya router yang punya. Paket orang asing ke your-router-public-ip:5060 mengenai router yang tidak punya pemetaan untuknya dan dibuang.

Bagi aplikasi P2P, inilah seluruh permainannya. Kedua peer berada di balik router yang hanya meneruskan paket jika ingat pernah mengirim sesuatu keluar lebih dulu. Tak satu pihak pun bisa begitu saja “menelepon” yang lain — mereka harus bekerja sama dengan router masing-masing untuk membuka jalur sementara.

Hole punching: membuat firewall mengizinkan Anda masuk kembali

Inilah triknya. Tabel NAT router Anda berkunci pada lima-tuple: IP sumber, port sumber, IP tujuan, port tujuan, dan protokol. Ketika perangkat Anda mengirim paket UDP keluar ke 1.2.3.4:5678, router membuat entri sementara yang berbunyi “jika ada paket UDP kembali dari 1.2.3.4:5678 ke IP publik saya pada port X, teruskan ke perangkat ini pada port Y.”

Entri itu ada untuk jangka waktu tertentu — biasanya 30 sampai 60 detik — lalu kedaluwarsa kecuali ada yang menyegarkannya. Selama jendela itu, paket apa pun dari alamat tujuan akan diterima.

Inilah lubang kunci yang dipakai aplikasi P2P. Jika kedua peer saling tahu alamat publik masing-masing, mereka bisa masing-masing mengirim satu paket UDP keluar ke pihak lain pada saat bersamaan. Router tiap sisi membuka pemetaan keluar. Paket pertama tiap sisi mungkin saja dibuang — router yang lain belum membuka pemetaannya — tetapi paket kedua sudah punya tujuan. Sejak saat itu, kedua router mengira mereka meneruskan percakapan keluar yang normal, dan kedua perangkat berbicara langsung.

Ini disebut UDP hole punching. Agak ajaib, terdokumentasi dengan baik (RFC 5128), dan berhasil untuk sebagian besar NAT konsumen di dunia nyata. Kasus yang tersisa — NAT simetris, CGNAT, firewall perusahaan — itulah alasan TURN ada.

Hole punching bukan peretasan. Ia adalah kontrak eksplisit tempat NAT dirancang: paket keluar menciptakan izin masuk. Aplikasi P2P hanya mengirim paket keluar itu dengan sengaja.

STUN: “apa alamat publik saya?”

Hole punching punya satu prasyarat: setiap peer harus tahu alamat publiknya sendiri agar bisa memberi tahu pihak lain ke mana harus mengirim paket. Alamat itu tidak terlihat dari dalam perangkat. iPad Anda melihat alamat Wi-Fi lokalnya (192.168.1.42). Yang dilihat seluruh Internet setelah router menulis ulang paket adalah sesuatu yang sama sekali berbeda.

STUN — Session Traversal Utilities for NAT, RFC 5389 — adalah protokol mungil yang menyelesaikan ini. Alurnya nyaris memalukan sederhananya:

1. Peer mengirim paket UDP ke server STUN publik. (Remio memakai server STUN publik Cloudflare dan Google demi redundansi.)
2. Server STUN membaca IP dan port sumber dari kabel — yang, menurut definisi, adalah alamat publik peer hasil translasi NAT.
3. Server STUN membalas dengan alamat itu sebagai muatan: “Sejauh yang saya lihat, Anda adalah 203.0.113.42:48291.”
4. Peer kini tahu alamat mana yang harus diumumkan ke pihak lain.

Alamat publik itu disebut server-reflexive candidate dalam istilah ICE. Biayanya nyaris nol — satu round trip saat penyiapan koneksi, dan nol bandwidth atau latensi tambahan setelah koneksi terbentuk. Satu-satunya tugas STUN adalah memperkenalkan dua peer satu sama lain; setelah mereka berbicara, server STUN tidak berperan lagi.

TURN: ketika hole punching gagal

Hole punching berfungsi untuk sebagian besar NAT, tetapi tidak semua. Kasus kegagalannya nyata, dan aplikasi P2P yang berpura-pura kasus itu tidak ada akan gagal terhubung bagi sebagian pengguna yang berarti.

Biang keladi utamanya:

• NAT simetris. NAT yang memberi port publik berbeda untuk setiap tujuan yang berbeda. STUN memberi tahu peer Anda bahwa Anda ada di port 48291 (karena itulah port yang dilihat server STUN), tetapi ketika Anda mengirim paket ke alamat peer Anda, router memilih port lain — katakanlah 48317. Router peer menolak paket itu karena datang dari port yang tidak terduga. Hole punching gagal.
• Carrier-grade NAT (CGNAT). Jaringan seluler dan banyak ISP menumpuk NAT kedua di tingkat operator. Anda mungkin berada di balik dua NAT tanpa sadar, dan keduanya harus bekerja sama. CGNAT sering bersifat simetris, dan Anda tidak punya akses admin ke sana.
• Firewall perusahaan yang ketat. Sebagian jaringan enterprise memblokir semua UDP keluar, atau hanya mengizinkannya ke tujuan tertentu. Hole punching butuh jalur UDP; jika tidak ada, ia tidak punya peluang.

Untuk kasus-kasus ini, cadangannya adalah TURN — Traversal Using Relays around NAT, RFC 5766. Server TURN adalah relay yang bisa dijangkau kedua peer karena punya alamat publik yang selalu menerima lalu lintas masuk. Setiap peer membuat koneksi TLS keluar biasa ke server TURN (yang diizinkan NAT mana pun), dan server meneruskan byte antara kedua sisi.

TURN punya biaya nyata. Setiap paket video harus melewati satu hop jaringan tambahan. Pada relay TURN regional, itu menambah sekitar 30 sampai 80 milidetik latensi round-trip. Lintas wilayah — misalnya relay di Frankfurt untuk peer di Tokyo dan peer di São Paulo — bisa 80 sampai 200 milidetik. Operator TURN juga membayar bandwidth: setiap bit stream Anda melewati jalur mereka.

Inilah sebabnya aplikasi yang dirancang baik memakai TURN hanya ketika hole punching terbukti gagal. ICE menangani keputusan itu secara otomatis.

ICE: mencoba setiap kandidat secara paralel

Interactive Connectivity Establishment, RFC 8445, adalah koreografi yang mengikat semua ini. ICE tidak memilih strategi di awal. Ia mengumpulkan setiap alamat kandidat yang mungkin untuk tiap peer, bertukar daftar lengkap dengan pihak lain, lalu membuat kedua stack menguji setiap pasangan kandidat secara paralel — berlomba menemukan yang pertama berfungsi.

Untuk setiap peer, ICE biasanya mengumpulkan:

• Host candidate — setiap alamat IP lokal pada setiap antarmuka jaringan (Ethernet, Wi-Fi, antarmuka virtual, IPv4 dan IPv6).
• Server-reflexive candidate — alamat publik yang dipelajari dari server STUN.
• Relay candidate — alamat yang dialokasikan pada server TURN.

Kedua peer bertukar daftar ini lewat kanal signaling — untuk Remio, itu koneksi WebSocket kecil ke relay.remio.net yang membawa kandidat ICE dan deskripsi sesi WebRTC (SDP), lalu tidak punya tugas lagi begitu media mulai mengalir.

Setelah kedua daftar di tangan, ICE memulai connectivity check. Setiap peer mengirim paket STUN-binding-request di setiap pasangan kandidat, berurutan menurut prioritas. Prioritasnya dirancang untuk mengutamakan jalur berlatensi terendah:

1. Host ke host — kedua peer di jaringan lokal yang sama. Ini kasus idaman: latensi beberapa ratus mikrodetik, tanpa router.
2. Host ke server-reflexive, atau server-reflexive ke server-reflexive — peer di jaringan berbeda, di-hole-punch menembus NAT masing-masing. Inilah yang biasanya dimaksud “P2P lewat Internet” dalam praktik.
3. Apa pun yang melibatkan relay — pilihan terakhir, dipakai hanya ketika semua jalur berprioritas lebih tinggi gagal pada connectivity check.

Pasangan kandidat pertama yang berhasil di kedua arah dinominasikan sebagai pemenang, dan media mulai mengalir lewat jalur itu. Seluruh prosesnya biasanya selesai jauh di bawah satu detik.

ICE juga mengumpulkan kandidat secara terus-menerus. Jika jalur yang lebih baik muncul di tengah sesi — misalnya ponsel Anda meninggalkan seluler dan bergabung ke Wi-Fi — ICE bisa menominasikan ulang ke jalur baru tanpa memutus panggilan.

Mengapa Remio sangat mengutamakan P2P

Remio adalah aplikasi remote desktop, bukan panggilan video. Anggaran latensinya ketat. Agar sesi terasa seperti duduk di mesin host, seluruh pipeline — tangkap, encode, jaringan, decode, render — harus sangat kecil: di LAN biayanya sekitar 8 ms, dan sisanya adalah ritme refresh 60 Hz layar Anda sendiri (sekitar 16,7 ms per frame). Setiap hop tambahan adalah dosa.

Pada koneksi P2P LAN langsung, porsi jaringan dari anggaran itu sekitar 1 sampai 5 milidetik round-trip. Tidak ada relay; byte langsung berpindah dari satu perangkat ke yang lain. Dengan pipeline Remio, ini berjumlah sekitar 8 ms pemrosesan di LAN (diukur secara internal; sisanya adalah ritme refresh 60 Hz layar Anda sendiri) — input Anda tiba sebelum frame berikutnya digambar. Mesin jarak jauh terasa tak terbedakan dari mesin lokal.

Pada koneksi yang direlay TURN — bahkan yang regional — porsi jaringan melonjak menjadi 30 sampai 80 milidetik. Total latensi yang dirasakan pengguna kini 40 sampai 100 ms. Masih bisa dipakai untuk sebagian besar pekerjaan, tetapi terasa saat menyeret cepat atau mengeklik berturut-turut. Trackpad tidak terasa lagi benar-benar milik Anda.

Selisih itulah alasan kami bersusah payah menjaga sesi tetap di P2P. Stack WebRTC Remio mengumpulkan kandidat IPv4 dan IPv6, berbicara ke beberapa server STUN secara paralel, dan agresif mengutamakan jalur langsung saat pemilihan pasangan kandidat ICE. Secara internal kami bahkan memakai RTT koneksi yang terukur untuk mengklasifikasikan jaringan — di bawah 15 ms kami tahu itu LAN, sehingga encoder mulai tinggi dan boleh memakai bandwidth jauh lebih besar. Apa pun yang lebih lambat diperlakukan sebagai WAN dan disetel lebih konservatif.

Dan — bagian yang sering diam-diam dilewatkan kompetitor — koneksi terenkripsi end-to-end apa pun jalurnya. Layar Anda tidak pernah menyentuh server kami, dan bahkan relay TURN hanya melihat ciphertext: kunci dinegosiasikan langsung antara kedua peer saat handshake, sebelum satu piksel pun bergerak. Entah byte mengalir P2P atau lewat TURN, baik server signaling Remio maupun operator TURN tidak bisa membacanya. P2P hanya berarti tidak ada pihak ketiga sama sekali di jalur data.

Ketika relay tak terhindarkan (dan itu tidak apa-apa)

Kadang dewa jaringan berkata tidak. NAT simetris di kedua ujung, double-CGNAT di operator seluler dengan ISP yang ketat, firewall perusahaan yang hanya mengizinkan TLS keluar ke penyedia cloud yang dikenal — ini konfigurasi nyata dan umum. Dalam kasus itu, sesi harus melewati relay atau tidak terjadi sama sekali.

Backend TURN Remio adalah Cloudflare Calls, yang memberi kami jaringan relay global di dekat sebagian besar pengguna. Ketika ICE memilih jalur relay, pengalaman turun dari “terasa lokal” menjadi “terasa seperti Splashtop” — masih sangat bisa dipakai, tetapi terasa bedanya. Latensi tambahan sebesar 30 sampai 80 ms untuk relay regional; lintas wilayah bisa mencapai 200 ms.

Bagian pentingnya: data tetap terenkripsi end-to-end. Cloudflare melihat paket UDP terenkripsi ke satu arah dan paket UDP terenkripsi ke arah lain. Ia bisa menghitung byte untuk penagihan. Ia tidak bisa melihat layar Anda, ketikan Anda, atau isi sesi Anda sama sekali. Tidak ada titik dekripsi di sisi Remio juga, karena tidak ada cloud Remio dalam pipeline — kami mengoperasikan layanan TURN lewat Cloudflare dan tidak pernah menyentuh muatannya.

Inilah arsitektur yang diuraikan lebih rinci dalam whitepaper keamanan kami. Intinya: P2P atau relay, model ancamannya sama.

Jalan keluar IPv6

IPv6 punya 340 undesiliun alamat (3,4 × 10³⁸) — cukup untuk memberi setiap butir pasir di Bumi IP publiknya sendiri, dengan beberapa triliun tersisa. Di dunia yang hanya IPv6, NAT sebagian besar tidak diperlukan. Dua perangkat berkemampuan IPv6 bisa langsung saling mengirim paket ke alamat masing-masing, dan satu-satunya hambatan adalah firewall host di kedua ujung.

Jika Anda punya IPv6 di rumah dan di operator seluler, Anda mungkin memperhatikan bahwa sebagian aplikasi terhubung lebih cepat ketika kedua ujung memakai IPv6 — itu karena seluruh tarian “kumpulkan kandidat, uji pasangan” punya lebih sedikit hambatan. Tidak ada translasi NAT yang perlu ditemukan, tidak perlu perjalanan ke STUN, hanya alamat langsung.

Tetapi ada masalahnya: pada 2026 penerapan globalnya masih belum lengkap. Banyak router rumah mendukung IPv6 dengan buruk atau tidak sama sekali. Banyak jaringan perusahaan memblokir IPv6 masuk secara default. Sebagian operator menawarkan IPv6 di sisi radio tetapi menjembatani ke IPv4 di tempat lain. Jalur IPv6-ke-IPv6 murni memang ada tetapi tidak bisa diandalkan sebagai satu-satunya mekanisme.

Jadi Remio — seperti setiap stack P2P yang serius — mengumpulkan kandidat IPv4 maupun IPv6, dan membiarkan ICE mengadu keduanya. Jika jalur IPv6 langsung ada dan berfungsi, biasanya ia menang soal latensi. Jika tidak, IPv4 dengan hole punching mengambil alih. Jika keduanya gagal, relay. Pengguna tidak pernah melihat semua ini; koneksi hanya terbentuk.

Cara mengetahui jalur mana yang dipakai sesi Anda

Penasaran sesi Anda berakhir di jalur mana? Indikator koneksi Remio menampilkan jenisnya dalam bahasa sederhana — “Langsung” untuk P2P, “Relay” untuk TURN. Panel statistik developer menampilkan seluruh status WebRTC, termasuk jenis kandidat pasangan yang dinominasikan (host, srflx, relay) dan RTT terukur.

Beberapa interpretasi cepat:

• RTT di bawah 5 ms, Langsung — Anda berada di LAN yang sama dengan host. Kasus terbaik. Sekitar 8 ms pemrosesan (sisanya adalah ritme refresh 60 Hz layar Anda sendiri) bisa dicapai.
• RTT 5 sampai 15 ms, Langsung — jaringan Wi-Fi yang sama tetapi dengan satu hop access point atau mesh tambahan. Tetap sangat baik.
• RTT 15 sampai 80 ms, Langsung — Anda berada di jaringan berbeda dari host, hole punching berhasil. P2P Internet berfungsi.
• RTT 30 sampai 80 ms, Relay (regional) — NAT simetris atau carrier-grade NAT menggagalkan hole punch. TURN Cloudflare terdekat mengambil alih.
• RTT 80 sampai 200 ms, Relay — TURN melalui jarak geografis yang lebih jauh, atau Anda dan host berada di wilayah yang sangat berbeda.

Jika Anda secara konsisten jatuh ke relay bahkan di rumah, tersangka yang lazim adalah modem ISP yang melakukan NAT simetris, CGNAT IPv4 pada koneksi rumah Anda (lebih umum dari yang dikira pada reseller fiber), atau firewall yang terlalu bersemangat memblokir UDP masuk. Panduan mengurangi lag remote desktop kami menelusuri biang yang umum, dan halaman koneksi LAN langsung adalah jalan pintas jika kedua perangkat ada di jaringan Anda.

Angka performa dunia nyata

Menyatukan semuanya, berikut angka latensi yang kami ukur di produksi pada berbagai jalur yang bisa dilalui sesi Remio:

• P2P LAN langsung: RTT jaringan 1–5 ms. End-to-end (event input hingga pembaruan piksel): sekitar 8 ms pemrosesan (sisanya adalah ritme refresh 60 Hz layar Anda sendiri) dengan seluruh pipeline bekerja sama.
• Wi-Fi jaringan sama dengan hop tambahan: RTT jaringan 5–10 ms.
• Relay TURN, regional: RTT jaringan 30–80 ms.
• Relay TURN, lintas wilayah: RTT jaringan 80–200 ms.
• Seluler 4G/5G, P2P hasil hole punch: RTT jaringan 40–100 ms.

Angka ini sesuai dengan benchmark Remio dan menjelaskan mengapa kami menetapkan ambang LAN-vs-WAN di RTT 15 ms — ia memisahkan dengan bersih jalur langsung dari relay mana pun (minimum 30 ms) atau jalur seluler (minimum 40 ms), dengan sangat sedikit positif palsu.

NAT traversal adalah salah satu topik yang protokolnya sederhana secara individual tetapi kombinatoriknya rumit. Sebagian besar pengguna tidak akan pernah perlu tahu ICE, STUN, dan TURN ada — mereka hanya merasakan aplikasi yang terhubung cepat dari mana saja ke mana saja. Protokol itu menjalankan tugasnya ketika Anda tidak menyadarinya. Ketika Anda menyadarinya — sesi butuh sedikit lebih lama, atau “Langsung” berubah menjadi “Relay” — sekarang Anda punya model mentalnya.

Untuk lebih lanjut tentang pipeline native Remio dan pilihan yang mengubah latensi jaringan 1–5 ms menjadi sekitar 8 ms pemrosesan (sisanya adalah ritme refresh 60 Hz layar Anda sendiri), lihat mengapa native itu penting. Untuk model ancaman pada jalur relay, lihat whitepaper keamanan. Atau cukup jelajahi fiturnya dan unduh Remio untuk merasakannya bekerja.