Dua situs seluler tanpa port masuk: bangun hub yang berfungsi

Dua situs pada uplink seluler menghadapi masalah yang sama di kedua arah: keduanya tidak dapat menerima koneksi IPv4 tak diminta, sehingga keduanya tidak dapat berperan sebagai server dalam terowongan langsung. Arsitektur yang berhasil menempatkan pihak ketiga yang dapat dijangkau di tengah: setiap situs menghubungi keluar dan pihak tengah hanya meneruskan lalu lintas yang Anda setujui. Pihak tengah itu bisa berupa router yang Anda kelola atau produk yang memperkenalkan peer, dan keduanya bukan hal yang sama. Langkah-langkah di bawah ini diurutkan agar masing-masing menghasilkan bukti sebelum langkah berikutnya bergantung padanya.

Tidak ada situs yang bisa dihubungi, jadi keduanya harus menghubungi keluar

Konfirmasikan batasan sebelum merancang di sekitarnya. Jika operator memberikan alamat privat ke antarmuka WAN, tidak ada penerusan port pada router situs itu sendiri yang membuatnya dapat dijangkau, karena terjemahan terjadi di hulu. Alamat IPv6 publik dapat ada pada uplink yang sama dan mengubah rancangan sepenuhnya, itulah sebabnya pemeriksaan mencakup kedua keluarga. Catat jawabannya per situs, karena keduanya jarang memiliki batasan yang identik meski berbagi operator.

Kasus seluler biasa tampak seperti alamat dari rentang terjemahan operator dengan rute default yang melewatinya. Itu bukan kerusakan yang harus diperbaiki; itulah alasan hub itu ada. Yang Anda cari adalah alamat apa pun yang dapat dijangkau pihak ketiga tanpa situs itu berbicara lebih dulu.

Dua perintah menjawab pertanyaan pengalamatan untuk situs yang ada di depan Anda. Jalankan di router situs, bukan di laptop di belakangnya:

ip -4 addr show scope global
ip -6 addr show scope global

Siapa yang memperkenalkan peer, dan siapa yang membawa paket

Perkenalan dan transportasi adalah pekerjaan terpisah yang sering digabung produk tanpa membuat batasnya terlihat. Mekanisme pertemuan membantu dua peer menemukan jalur kandidat; relai membawa paket mereka ketika tidak ada jalur langsung. Membeli layanan yang memperkenalkan peer tidak memberi Anda router, dan perbedaan itulah yang menentukan apakah rancangan memerlukan hub sama sekali.

Traversal punya kosakatanya sendiri, dan kata-katanya menggambarkan peran, bukan jaminan. Spesifikasi ICE menjelaskan kandidat dan pemeriksaan konektivitas, STUN menjelaskan satu cara mempelajari terjemahan alamat, dan TURN menjelaskan transportasi melalui relai bagi aplikasi yang menerapkannya. Tidak satu pun mekanisme itu muncul di gateway biasa karena Anda mengarahkannya ke alamat penemuan. Verifikasi traversal sebagai kemampuan produk, dan anggap ada relai sampai sebuah uji menunjukkan sebaliknya.

Satu rute per situs, dimiliki seorang peer

Hub memerlukan satu terowongan per situs, prefiks LAN berbeda di belakang masing-masing, dan rute untuk setiap prefiks yang menyebut pemiliknya. Dalam contoh hub adalah 10.61.0.1, situs A adalah 10.61.0.11 dengan LAN 10.60.10.0/24, dan situs B adalah 10.61.0.12 dengan LAN 10.60.20.0/24. Setiap rute di bawah menunjuk ke peer yang memiliki prefiks itu, bukan ke antarmuka terowongan:

ip route add 10.60.10.0/24 via 10.61.0.11 dev wg0
ip route add 10.60.20.0/24 via 10.61.0.12 dev wg0
sysctl net.ipv4.ip_forward
ip route get 10.60.20.55 from 10.60.10.77

Penerusan harus diaktifkan, jika tidak paket berhenti di hub tanpa galat yang menunjuk penyebabnya. Perintah terakhir menjawab pertanyaan sebenarnya, karena menanyakan jalur mana yang akan diambil paket dari LAN situs A ke LAN situs B dengan sumber disertakan dalam pencarian. Perlakukan pencarian yang menyebut antarmuka terowongan sebagai bukti dan yang jatuh ke rute default sebagai rute yang hilang, bukan misteri. Lalu batasi transit dengan sengaja, karena hub yang meneruskan antar semua peer mengubah dua situs menjadi jaringan datar dan kebijakan akses yang Anda kira miliki berhenti berlaku.

Putuskan juga di mana enkripsi berakhir. Ketika hub memegang kedua ujung terowongan, operator mesin itu dan beban kerjanya masuk ke model kepercayaan dan ketersediaan, dan lebar pita mesin itu menjadi bagian dari jalur.

Jaga setiap pemetaan tetap hidup melalui operator

Setiap situs memulai terowongannya sendiri, dan masing-masing harus menjaga pemetaan terjemahan tetap hidup atau operator melupakannya. Pesan jaga-hidup di sisi yang memulai mempertahankan pemetaan itu di antara jabat tangan. Batasi prefiks yang diizinkan ke alamat hub dan LAN jarak jauh, agar peer yang disusupi tidak dapat mengklaim prefiks yang bukan miliknya:

[Peer]
PublicKey = <hub public key>
Endpoint = 192.0.2.10:51820
AllowedIPs = 10.61.0.1/32, 10.60.20.0/24
PersistentKeepalive = 25

Cerminkan blok di situs lain dengan prefiks jarak jauhnya sendiri, dan tahan dorongan untuk mengizinkan seluruh rentang terowongan. Jabat tangan yang berhenti dan melanjutkan dari port sumber baru adalah tanda pemetaan kedaluwarsa, dan stempel waktu jabat tangan adalah bukti bahwa itu terjadi. Interval yang lebih pendek dari batas waktu operator mencegah kedaluwarsa alih-alih memperbaikinya setelahnya. Ketika operator mengubah perilaku terjemahannya, perkirakan waktu-waktu itu ikut berubah.

Buktikan kedua arah, lalu buktikan pemulihan

Verifikasi bersifat terarah, jadi ping dari A ke B membuktikan separuh rancangan dan tidak apa pun tentang rute kembali. Periksa jalur balasan dengan pencarian peka sumber yang sama di hub, lalu ulangi uji dari sisi lain. Jabat tangan baru juga termasuk bukti, karena terowongan yang menganggur satu jam mungkin menguji pemetaan lama:

wg show wg0 latest-handshakes
ping -c 3 10.60.20.55
traceroute -n 10.60.20.55

Lalu uji kegagalan yang Anda perkirakan, bukan keberhasilan yang Anda inginkan. Mulai ulang uplink satu situs dan pastikan terowongan kembali tanpa manusia menyentuh kedua ujungnya, karena rancangan yang memerlukan operator setelah setiap perubahan di operator belum selesai. Catat jalur utama, alternatif IPv6 bila ada, dan perilaku saat hub tidak tersedia. Hub kini bagian dari model ketersediaan Anda, jadi catatlah itu alih-alih menemukannya saat gangguan.