WireGuard 5G cabang: biarkan cabang menghubungi hub

Mengarahkan cabang ke hub adalah separuh mudah dari desain ini ketika cabang berada di belakang alamat seluler yang berubah dan hub memiliki nama yang stabil. Hub lalu mempelajari cabang dari lalu lintas yang terautentikasi, bukan dari catatan yang harus Anda jaga tetap mutakhir. Kontraknya sederhana: cabang selalu memulai.

Konfigurasikan dengan sengaja, lalu verifikasi bagian yang orang anggap bekerja. Kedua langkahnya butuh beberapa menit, dan pada langkah keduanya desain seperti ini biasanya gagal.

Sisi mana yang memegang titik akhir stabil

Konfigurasi cabang menyebut titik akhir dan kunci publik hub. Konfigurasi hub menyebut kunci publik cabang dan prefiks dalam yang diizinkan, dan mungkin tidak memuat titik akhir sama sekali, karena identitas datang dari kunci dan bukan dari alamat sumber paket terakhir. Asimetri itulah seluruh mekanismenya, dan itu menghapus satu kelas masalah penemuan dari sisi hub.

Saat cabang mengirim paket terautentikasi, hub mencatat sumber dari mana paket itu datang dan memakai pemetaan itu untuk balasan. Penomoran ulang tautan seluler kemudian tidak memakan biaya apa pun selain jabat tangan berikutnya, dan setiap komponen yang tidak lagi Anda butuhkan adalah komponen yang tidak bisa gagal saat pengalihan. Sifat itu layak diuji saat perubahan terjadwal, bukan saat insiden. Lakukan saat seseorang dapat memantau kedua ujung sekaligus.

Beri cabang konfigurasi yang bertahan saat penomoran ulang

Pertahankan titik akhir dan keepalive di cabang, dan jaga entri peer hub bebas dari alamat yang dikodekan keras. Keepalive menahan pemetaan terjemahan tetap terbuka cukup lama agar hub dapat mengirim lalu lintas tak diminta setelah periode diam.

[Peer]
PublicKey = HUB_PUBLIC_KEY_BASE64
Endpoint = hub.example.net:51820
AllowedIPs = 10.60.0.0/24, 10.60.10.0/24
PersistentKeepalive = 25

Dua puluh lima detik adalah contoh yang sering dikutip untuk menjaga pemetaan NAT tetap hidup, bukan keharusan bagi setiap peer. Aturlah berdasarkan batas waktu pemetaan yang benar-benar Anda amati, dan ingat bahwa itu menghasilkan lalu lintas pada tautan berkuota data selama antarmuka menyala.

Di hub, prefiks yang diizinkan untuk peer cabang harus mencakup semua yang akan dikirim cabang. Prefiks yang hilang berperilaku seperti kegagalan perutean di ujung jauh dan tidak menghasilkan peringatan di kedua sisi, karena itu layak ditinjau sebelum paket nyata pertama. Bandingkan prefiks yang diizinkan di hub dengan alamat antarmuka cabang sebelum koneksi pertama.

Verifikasi pemetaan dan pengalihannya

Pastikan jabat tangan selesai, hub mencantumkan titik akhir cabang saat ini, dan alamat dalam cabang dapat dijangkau melalui terowongan. Itulah garis dasar, dan sebaiknya dicatat sebelum siapa pun menyentuh tautan seluler. Dua baris keluaran sudah cukup. Simpan di tiket bersama stempel waktu.

wg show wg0
wg show wg0 latest-handshakes
ip route show default
ping -c 3 10.60.10.1

Lalu uji kegagalan yang menjadi alasan desain ini ada. Cabut WAN utama dan pastikan rute dasar cabang ke hub kini keluar melalui antarmuka seluler. Terowongan tidak dapat memperbaiki jalur fisik yang rusak, jadi rute luar yang masih menunjuk ke uplink mati menghasilkan batas waktu jabat tangan yang tampak persis seperti masalah hub.

Jika jalur luar terikat secara eksplisit atau dirutekan oleh kebijakan, pengalihan harus mencakupnya. Celah antara desain yang terbaca benar dan desain yang bertahan saat pemadaman biasanya hanya satu hal yang kurang.

Apa yang tidak diselesaikan desain ini

Tidak ada yang mengizinkan koneksi masuk ke cabang di sini. Jika sesuatu di kantor pusat harus menghubungi situs seluler, arah terowongan salah untuk kebutuhan itu, dan DNS dinamis hanya memperbarui nama. Terjemahan penyedia, kebijakan masuk, dan penyegaran titik akhir oleh klien semuanya tetap menghalangi, dan catatan yang berubah tidak dapat membuka NAT tingkat operator.

Jaga prefiks cabang berbeda dari setiap situs lain, dan batasi apa yang akan diteruskan gateway-nya. Titik akhir hub yang stabil menyederhanakan penemuan dan tidak melakukan apa pun untuk desain perutean, perencanaan alamat, atau pertanyaan rute aplikasi mana yang bertahan saat pengalihan.

Tulis empat hal di runbook: siapa yang memulai, prefiks mana yang diizinkan, berapa lama keepalive, dan apa yang terjadi saat tautan utama putus. Baris-baris itulah yang benar-benar dibutuhkan operator mendatang pada pukul tiga pagi.