Empat pertanyaan mendahului setiap perubahan pengaturan: apakah sumber daya yang sama berfungsi saat klien aktif, berapa lama periode menganggurnya, apakah perangkat tidur atau berganti jaringan, dan apakah kegagalan hanya muncul pada lalu lintas yang dimulai sisi jauh. Jawabannya memisahkan pemetaan NAT yang kedaluwarsa dari radio yang tidur dan dari aplikasi yang basi. Jawaban itu juga memberi tahu apakah keepalive sama sekali relevan. Mulailah dari arah, karena biayanya satu perintah dan menyingkirkan separuh kemungkinan penyebab.

Arah mana yang gagal?

Permintaan keluar baru dari klien dan lalu lintas yang tiba ke arahnya setelah periode tenang menguji perangkat berstatus dengan cara berbeda. Paket keluar membangun ulang pemetaan saat pergi, sedangkan paket masuk membutuhkan pemetaan lama tetap bertahan. Asimetri itulah seluruh ujinya. Jika klien bisa keluar tetapi tidak ada yang masuk, pemetaannya kemungkinan kedaluwarsa, dan jika keduanya tidak berfungsi, tunnel atau akses jaringan klien hilang.

Catat berapa lama periode tenang berlangsung dan apakah perangkat tidur atau berpindah ke jaringan lain sementara itu. Kedua fakta itu mengubah diagnosis sebelum pengaturan apa pun.

wg show wg0 latest-handshakes
wg show wg0 endpoints
wg show wg0 transfer

Jalankan ketiganya sebelum dan sesudah periode tenang, karena masing-masing menjawab bagian pertanyaan yang berbeda. Stempel waktu handshake yang tidak bergerak mengatakan kedua pihak berhenti bicara, sedangkan titik akhir yang berubah mengatakan pemetaan berpindah, bukan mati. Penghitung transfer menunjukkan apakah ada yang tiba sama sekali, dan itulah bedanya antara pemetaan basi dan aplikasi yang diam. Tuliskan angkanya di kedua titik, karena perbandingannya adalah buktinya.

Tidur, radio, dan keadaan aplikasi

Di ponsel atau laptop, perangkat yang tidur mungkin kehilangan akses jaringan sepenuhnya, dan keepalive tidak dapat memulihkan radio yang mati atau menyelesaikan captive portal yang belum dipenuhi. Platform seluler menangguhkan pekerjaan latar sebagai kebijakan, jadi apakah lalu lintas berkala berlanjut bergantung pada platform dan pada apa yang dinegosiasikan aplikasi dengannya. Koneksi yang di-cache adalah kasus ketiga dan paling menyesatkan, karena kembalinya tunnel tidak sama dengan aplikasi menyambung ulang ke sana.

Buka kembali aplikasi setelah periode menganggur alih-alih memercayai tab yang tetap terbuka. Jika permintaan baru berhasil di tempat sesi lama gagal, tunnel tidak pernah menjadi masalahnya.

Apa yang sebenarnya dilakukan keepalive

PersistentKeepalive mengirim paket kosong terautentikasi secara berkala ke peer, yang cukup untuk menjaga pemetaan NAT tetap hidup di antara peer dan membuat titik akhir pihak lain tetap mutakhir, seperti yang dijelaskan mulai cepat WireGuard. Ia tidak memperbaiki radio yang tidur, rute yang hilang, atau aplikasi yang tidak pernah mencoba lagi. Pilih interval melalui pengaturan klien yang didukung, dan jangan mengaktifkan nilai agresif di mana-mana hanya karena tampilan status menjadi diam.

Sebagian besar periode menganggur bukan kegagalan. Tunnel yang tersambung lagi setelah lima menit hening berperilaku benar, dan masalahnya hanya kasus ketika sesuatu seharusnya tiba dari sisi jauh.

Tunggu interval yang dulu gagal

Lakukan satu perubahan yang didukung, lalu biarkan periode menganggur yang sama berlalu sebelum menguji ulang sumber daya itu. Menunggu adalah bagian dari uji, bukan formalitas. Keberhasilan langsung setelah tersambung ulang tidak mengatakan apa pun tentang gejala menganggur lama, karena tersambung ulang justru peristiwa yang mereset keadaan. Jika masalahnya juga muncul saat penggunaan aktif, kembali ke pemeriksaan handshake dan jalur data alih-alih menambahkan lebih banyak lalu lintas berkala.

Pertahankan satu perubahan per uji dan catat durasi menganggur yang dipakai. Tanpa itu, setiap perbandingan berikutnya melenceng dan tidak ada yang bisa mengatakan perubahan mana yang penting. Catat keempat faktanya bersama: arah, durasi, keadaan tidur, dan perilaku aplikasi.

Artikel terkait