VPN terus terputus? Tangani dengan urutan ini

Sebelum memasang ulang klien, catat tiga hal: berapa lama terowongan bertahan, apa yang dikatakan klien saat terputus, dan apakah mesin tidur atau berganti jaringan di antaranya. Catatan itu satu-satunya bukti yang nanti Anda miliki, dan pemasangan ulang biasanya menghapusnya. Putus pada interval berulang berarti pengatur waktu atau keadaan yang kedaluwarsa; putus pada saat acak berarti masalah jalur. Urutan di bawah mencegah Anda mengubah tiga hal sekaligus dan tidak belajar apa pun.

Langkah pertama: catat interval dan teks kesalahan

Mulai dari log klien itu sendiri, bukan dasbor penyedia. Pada klien Linux, log layanan ditambah keadaan terowongan langsung mencakup sebagian besar:

journalctl -u openvpn-client@client --since '3 hours ago' | tail -60
journalctl -u wg-quick@wg0 --since '3 hours ago' | tail -40
wg show
ip -s link show wg0

Catat stempel waktu jabat tangan terakhir yang berhasil dan saat lalu lintas berhenti, bukan hanya saat ikon berubah warna. Klien GUI yang mengatakan terputus setelah kejadian mungkin melaporkan keadaan yang dicapai kernel beberapa detik sebelumnya.

Pertahankan kata-kata kesalahannya. Waktu habis, penolakan autentikasi, dan kesalahan adaptor atau pengandar menunjuk ke tiga lapisan berbeda, dan sebagian besar usaha yang terbuang dalam masalah ini berasal dari memperlakukannya sebagai satu. Salin baris itu apa adanya ke catatan Anda.

Langkah kedua: ubah satu variabel, bukan profil

Pertahankan perangkat dan profil tetap dan pindahkan mesin ke jaringan akses lain, seperti hotspot ponsel. Ini uji termurah yang memisahkan klien dari jalur. Jalankan cukup lama untuk mencakup interval kegagalan awal; dua menit stabil tidak membuktikan apa pun tentang putus yang terjadi pada menit ketiga puluh.

Laptop dengan porta Ethernet memberi perbandingan kedua yang mengeluarkan Wi-Fi sepenuhnya dari gambaran. Jika terowongan bertahan pada kedua alternatif, jaringan akses awal patut diperhatikan: roaming antar-titik akses, router rumah yang tabel terjemahannya kedaluwarsa, atau tautan hulu yang mereset aliran berumur panjang.

Catat variabel mana yang Anda ubah. Perbandingan hanya berlaku bila semua hal lain tetap sama, dan itu mencakup titik akhir server serta waktu dalam hari.

Langkah ketiga: petakan interval ke lapisan

Lama sesi yang baik adalah satu angka paling informatif yang Anda punya. Bacalah terhadap daftar ini sebelum menyentuh pengatur waktu:

• Putus setelah tidur atau bangun: keadaan terowongan bertahan melewati penangguhan tetapi antarmuka tidak. Periksa perilaku penyambungan ulang klien saat bangun dan apakah layanan memulai ulang terowongan atau menunggu lalu lintas.
• Putus hanya saat menganggur: sesuatu di tengah membiarkan aliran kedaluwarsa. Untuk kasus itulah keepalive ada.
• Putus pada usia sesi tetap: peristiwa autentikasi ulang atau pembaruan kunci, bukan kegagalan jalur. Penolakan eksplisit di log tepat pada interval itu adalah tandanya.
• Putus selama transfer besar atau halaman besar: curigai MTU dan fragmentasi, bukan pengatur waktu menganggur.

Untuk kasus menganggur, pengaturannya bergantung pada protokol dan kedua ujungnya penting. keepalive 10 60 OpenVPN di server mengirim ping setiap 10 detik dan memulai ulang tautan setelah 60 detik tanpa ping; klien WireGuard di belakang NAT memakai PersistentKeepalive = 25 di blok rekan. OpenVPN juga menegosiasikan ulang kanal data dengan pengatur waktu, reneg-sec, yang secara bawaan 3600 detik pada 2.x.

Jangan menyalin nilai agresif dari panduan penyedia lain. Waktu habis pendek pada tautan seluler yang lossy justru menghasilkan putus yang seharusnya dicegah, dan nilai yang dikirim server mengalahkan yang Anda setel di profil klien.

Langkah keempat: bandingkan satu alternatif yang didukung

Jika operator menerbitkan profil UDP dan TCP, jalankan perangkat dan jaringan yang sama terhadap yang lain. Gunakan berkas yang benar-benar cocok, bukan menyunting transportasi di profil salinan. Profil TCP yang stabil pada jalur yang mereset UDP mempersempit masalah ke jalur itu; itu tidak membuktikan TCP adalah transportasi yang lebih baik di mana-mana.

Logika yang sama berlaku untuk titik akhir. Coba server lain dan simpan hasil awal di sebelahnya. Jika hanya satu jalan keluar yang mereset sesi, itu bukti tentang titik akhir tersebut, bukan alasan membangun ulang setiap adaptor di laptop.

Setelah setiap perubahan, ulangi pemicu awal dan pastikan ke mana lalu lintas benar-benar pergi. Akses internet yang pulih bukan hasil yang sama dengan lalu lintas di dalam terowongan, dan klien yang diam-diam jatuh ke rute langsung terlihat sehat dari peramban.

Verifikasi perbaikan, dan pertahankan rollback

Perbaikan diverifikasi dengan mereproduksi pemicu awal, bukan dengan koneksi yang berhasil. Biarkan terowongan menganggur melewati interval kegagalan lama, tangguhkan dan lanjutkan sekali, lalu periksa usia jabat tangan dan alamat keluar:

wg show wg0 latest-handshakes
curl -m 5 -sS https://ifconfig.me
cp client.ovpn client.ovpn.bak   # before editing timers

Pertahankan profil sebelumnya dan nilai pengatur waktu sebelumnya sampai perilaku baru bertahan satu hari kerja penuh. Jika putus kembali, pulihkan cadangan, lalu terapkan ulang perubahan satu per satu agar percobaan kedua mulai dari keadaan yang diketahui.

Jika log tetap bersih dan terowongan masih putus pada interval berulang, perhentian berikutnya adalah sisi server untuk sesi itu. Bawa pengenal sesi klien dan waktu putus yang tepat, karena pasangan itulah yang membuat log server dapat dicari. Opsi tautan protokol didokumentasikan di panduan OpenVPN 2.6 saat Anda membutuhkan makna tepat sebuah nilai.