Pada tulisan sebelumnya yang berjudul Apa & Mengapa menggunakan Tailscale gue lumayan banyak menyinggung tentang NAT. Tailscale adalah aplikasi yang lumayan cocok untuk gue jadikan contoh terkait aplikasi yang menggunakan koneksi p2p.
Tangkapan layar hasil tailscale status
Disitu terlihat jelas bahwa ada 2 jenis koneksi yang terjalin: direct (p2p) dan relay alias melalui TURN server. Melihat dari gambar diatas, alamat IP 100.122.66.17 berada di jaringan First Media yang tidak di satu daerah sama gue sedangkan untuk mesin yang memiliki prefix faultables- berada di 1 jaringan yang sama yakni Biznet alias di router gue yang memiliki alamat IP private 192.168.88.0/24.
Khusus untuk yang faultables-devbox itu berada di jaringan Digital Ocean yang mana gue buka port 41641/udp sehingga untuk koneksi yang mengarah ke mesin tersebut melalui jaringan Tailscale, paket yang ditukar langsung dari mesin tersebut dan tanpa “perantara” dari TURN server nya Tailscale.
ilustrasi
Nah pertanyaannya, mengapa perangkat zahra-iphone yang tidak berada di jaringan yang sama (First Media) dengan faultables-macbook (Biznet) tidak bisa berkomunikasi secara langsung sedangkan perangkat faultables-devbox yang tidak berada dalam jaringan yang sama juga (Digital Ocean) bisa?
Karena First Media dan Biznet adalah rival.
Hahaha tentu bukan karena itu.
Jika alasannya adalah karena itu, tentu gue tidak perlu capek-capek membuat tulisan ini :))
Mengenal NAT
Kunci utama yang harus diingat dari NAT adalah jika ada lebih dari 1 perangkat berada dalam 1 alamat IP publik yang sama, pasti jaringan tersebut memiliki NAT.
Ketika komputer gue mencoba untuk PING 1.1.1.1, ilustrasinya (yang disederhanakan) adalah seperti ini:
ilustrasi NAT
Alamat IP 182.253.151.214 adalah alamat IP publik (dinamis) yang diberikan oleh ISP ke router gue pada saat itu dan 1.1.1.1 adalah alamat IP publik statis yang dimiliki oleh jaringan Cloudflare.
Sekarang kita ke kasus faultables-macbook melakukan PING ke zahra-iphone melalui Tailscale yang ilustrasinya sederhananya seperti ini:
masalah pertama di P2P adalah tidak mengetahui alamat IP publik dari peer
Anggap di percobaan pertama si faultables-macbook tidak mengetahui alamat IP publik dari zahra-iphone, dengan bantuan STUN server, perangkat zahra-iphone akan memberitahu si STUN server tersebut kalau alamat IP publik dia adalah 140.0.231.60.
perangkat zahra-iphone memberitahu alamat IP publik nya ke Tailscale DERP
Oke sekarang si faultables-macbook sudah mengetahui alamat IP publik dari zahra-iphone yang berarti diagram sebelumnya sekarang menjadi seperti ini:
masalah kedua di P2P adalah tidak mengetahui kemana paket diteruskan
Masalah yang ada di ilustrasi diatas sekarang adalah router tidak mengetahui harus kemana paket tersebut diteruskan. Atau bisa juga karena router memblokir paket yang mau lewat dari port tersebut.
Alasannya beragam, yang paling gampang dipahami adalah karena sebelumnya belum pernah ada komunikasi yang lewat melalui port tersebut.
Alasan lain bisa saja port tersebut diblokir oleh Firewall yang berada di router.
Biasanya program VPN (yang menggunakan protokol UDP) akan melakukan “hole punching” untuk menentukan port mana yang bisa digunakan oleh 2 peer tersebut. Jika sekiranya tidak memungkinkan (misal karena salah satu peer berada dibelakang NAT yang kompleks) maka mau tidak mau paket tersebut harus diteruskan dari perangkat yang tidak berada dibelakang NAT yang kompleks, yang seringnya adalah melalui relay server atau TURN.
contoh PING dari 100.107.147.55 ke 100.122.66.17 via 68.183.179.66 (derp3-sin)
Sekarang komputer faultables-macbook bisa berkomunikasi dengan zahra-iphone deh!
P2P without TURN
Hampir tidak mungkin untuk membuat koneksi p2p yang fully decentralized tanpa central server. Masalah utama dari teknologi p2p selain dari kasus “peer routing” diatas (NAT) adalah “peer discovery” alias, bagaimana cara peer A bisa menemukan peer B?
Misal kita ingin membuat sebuah layanan yang memang benar-benar peer-to-peer yang fully decentralized dan tanpa middleman. Anggap, kita ingin membuat layanan ride sharing seperti Goride nya Gojek namun tanpa central server alias komunikasi terjalin langsung antara pengemudi dan penumpang sehingga tidak ada biaya tambahan untuk jatah preman.
Untuk dapat mencapai pendekatan diatas, ada beberapa hal yang bisa kita usahakan:
- Melakukan port forwarding ataupun DMZ di level router yang tentu saja hampir tidak mungkin dilakukan oleh non-power user
- Menggunakan cara hacky seperti yang dilakukan oleh pwnat yang dapat dipertimbangkan
- Melakukan automatic port forwading via uPnP yang sepertinya tidak kompatibel dibeberapa jaringan & juga uPnP dianggap kurang aman
- Melakukan “distributed” UDP Hole Punching yang terdengar keren 😛
Poin-poin diatas dapat membantu untuk melakukan “peer routing” tanpa harus terlalu bergantung dengan TURN server.
Masalah kedua sekarang ada “peer discovery” dan ini yang paling berat.
Kasus sederhananya, misal ketika gue ingin memesan Goride dari Ciheulang ke Starbucks Dipatiukur, bagaimana caranya agar si driver mengetahui & dapat mengambil pesanan tersebut sedangkan tidak ada central server sama sekali?
Dalam proses discovery, setidaknya ada 3 pendekatan yang bisa dilakukan:
- Multicast DNS alias mDNS. Cara ini sering digunakan bila berada di jaringan lokal yang sama.
- Random walk. Cara ini biasanya menggunakan DHT (Distributed Hash Table) lalu mencari peer melalui peer terdekat dengan terus menelusuri ke hash table tersebut.
- Bootstrap. Ini yang paling sederhana dan sepertinya banyak dipakai. Sayangnya bila menggunakan pendekatan ini terdapat central server.
Pendekatan lainnya mungkin bisa menggunakan Node Discovery Protocol v5 yang digunakan oleh sistem Ethereum, but anyway.
Menggunakan teknologi Bluetooth Low Energi (BLE) ataupun Apple AirDrop untuk iOS dan Nearby untuk Android pun sepertinya hampir tidak mungkin untuk kasus kita.
Gue belum mengetahui solusi dari masalah terkait peer discovery ini, tapi mari kita berimajinasi.
Pertama, jika melihat kembali tujuan dari kasus khayalan yang kita buat ini, intinya kita ingin menjalankan misi yang mulia™ yakni membuat sebuah layanan yang menghubungkan antara penumpang & pengemudi secara langsung tanpa orang tengah yang meminta fee demi alasan operasional.
Kedua, dalam sebuah sistem pasti ada operator. Ada moderator. Ada koordinator. Ada komunitas yang andil dalam memelihara sistem tersebut.
Ketiga, terdapat banyak masalah di sistem yang tersentralisasi dan begitupula di sistem yang terdesentralisasi.
Mengambil 3 pertimbangan yang ada diatas, bisa kita tarik kesimpulan bahwa kita tetap membutuhkan orang ketiga dalam sistem p2p namun bukan bertindak sebagai *middleman *alias memiliki peran serupa juga dengan penumpang & pengemudi, hanya berbeda tugas aja.
Dalam sistem desentralisasi pun kebanyakan memiliki sistem seperti itu. Ada miner di Bitcoin & Ethereum, ada seeder di Bittorrent, dsb.
Jadi, kembali ke bagian ‘NAT without TURN’ kesimpulannya adalah almost impossible dengan rancangan khususnya terkait sistem internet yang ada sekarang.
Yang gue bayangkan adalah si operator ini seperti Root DNS Server namun decentralized yang berperan hanya untuk membalas kalau peer DrvYyQSo1c1Ym7orWxLYvCrM2EmxFTANf8wXmmE7DWjhx memiliki alamat 143.198.198.198. Mungkin seperti Dynamic DNS namun decentralize gitu.
Kenapa gak TURN server aja sih?
Gak apa-apa, biar panjang aja.
Hahaha enggak enggak, TURN server ini memang membantu namun masalah yang sedang kita bahas disini kan di peer discovery meskipun TURN server ini sangat penting untuk peer yang berada dibelakang symmetric NAT.
Kita sudahi pembahasan yang terlalu jauh keluar konteks tentang p2p ini ya.
Sebenernya masih ada pertanyaan lagi: bagaimana caranya agar peer B mengetahui jika peer A ingin pergi ke Starbucks Dipatiukur dari Ciheulang?
Tapi karena pertanyaan itu terlalu keluar dari topik, jadi biarkan menjadi misteri saja untuk saat ini.
Mengapa harus peduli dengan NAT?
Karena jika kita ingin membuat koneksi yang terjalin secara peer-to-peer, kita harus tau tentang NAT juga.
Kesimpulan & Penutup
Sebagaimana yang disebutkan di tulisan sebelumnya bahwa pada tahun 2021 ini gue tertarik untuk mengulik tentang teknologi P2P terlebih teknologi p2p tidak selalu tentang Real Time Communication.
Mungkin kata “decentralize” pada tahun ini sedang panas-panasnya, dan gue sejujurnya tidak tau apakah harus senang atau sebaliknya. Sudah lama gue tertarik dengan Internet/Web 3.0 karena gue kurang senang juga dengan apa yang ada di internet sekarang yang terlalu tertutup, tersentralisasi serta dikuasai oleh pemain besar.
Beberapa gerakan yang ada di internet seperti teknologi Bitcoin & Ethereum yang membuat ‘setiap orang adalah bank’ possible menjadi langkah awal karena uang adalah salah satu bagian yang paling krusial di masyarakat. Meskipun teknologi tersebut digunakan relatif tersentraliasi—bergantung dengan marketplace/exchange—namun itu tinggal menunggu waktu.
Anyway, sebenarnya masih banyak yang ingin gue bagikan terkait decentralize tapi karena judul dari tulisan ini adalah tentang NAT jadi mari kita sudahi saja. Pengetahuan terkait NAT sangat penting dalam pembuatan teknologi yang menggunakan teknologi P2P yang mana tidak terlalu bergantung dengan sentral server yang mengatur terlalu banyak tugas.
Sebagai penutup, jika masih tidak mendapatkan kenapa sistem tersentralisasi itu kurang bagus, silahkan tinggal di Indonesia dan lihat bagaimana *censorship *dan *gatekeeper *berperan disini.