121 lines
11 KiB
Markdown
121 lines
11 KiB
Markdown
|
---
|
|||
|
|
title: Mengenal Network Address Translation (NAT)
|
|||
|
|
tags:
|
|||
|
|
- blog
|
|||
|
|
slug: mengenal-network-address-translation-nat
|
|||
|
|
date: 2021-05-22T18:44:09.000Z
|
|||
|
|
date_updated: 2021-08-01T04:54:01.000Z
|
|||
|
|
excerpt: Salah satu bekal untuk yang tertarik membuat apapun yang menggunakan koneksi p2p
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
Pada tulisan sebelumnya yang berjudul [Apa & Mengapa menggunakan Tailscale](https://s3.rizaldy.club/rizaldy-club-ghost/apa-itu-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"](https://en.wikipedia.org/wiki/UDP_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](https://github.com/samyk/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](https://en.wikipedia.org/wiki/Bluetooth_Low_Energy#Mesh_profiles)) 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](https://www.duckdns.org) 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](https://s3.rizaldy.club/rizaldy-club-ghost/apa-itu-mengapa-menggunakan-tailscale/) 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](https://stratechery.com/2021/internet-3-0-and-the-beginning-of-tech-history/) 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.
|