VPN kerap terputus? Ikut urutan ini

Sebelum memasang semula klien, catat tiga perkara: berapa lama terowong bertahan, apa yang dikatakan klien semasa terputus, dan sama ada mesin tidur atau bertukar rangkaian dalam pada itu. Nota itu satu-satunya bukti yang anda akan ada kemudian, dan pemasangan semula biasanya memadamnya. Putusan pada selang yang berulang ialah pemasa atau tamat tempoh keadaan; putusan pada saat rawak ialah masalah laluan. Urutan di bawah menghalang anda mengubah tiga perkara sekali gus dan tidak belajar apa-apa.

Langkah satu: catat selang dan teks ralat

Mulakan dengan log klien sendiri dan bukan papan pemuka pembekal. Pada klien Linux, log perkhidmatan serta keadaan terowong secara langsung merangkumi sebahagian besarnya:

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 cap masa jabat tangan terakhir yang berjaya dan saat trafik berhenti, bukan hanya saat ikon bertukar warna. Klien GUI yang berkata terputus selepas kejadian mungkin melaporkan keadaan yang dicapai oleh kernel beberapa saat lebih awal.

Kekalkan perkataan ralat itu. Tamat masa, penolakan pengesahan dan ralat penyesuai atau pemacu menunjuk kepada tiga lapisan berbeza, dan sebahagian besar usaha yang terbuang dalam masalah ini datang daripada menganggapnya sebagai satu. Salin baris itu secara verbatim ke dalam nota anda.

Langkah dua: ubah satu pemboleh ubah, bukan profil

Kekalkan peranti dan profil tetap dan pindahkan mesin ke rangkaian capaian lain, seperti hotspot telefon. Ini ujian paling murah yang memisahkan klien daripada laluan. Jalankannya cukup lama untuk meliputi selang kegagalan asal; dua minit stabil tidak membuktikan apa-apa tentang putusan yang berlaku pada minit ketiga puluh.

Komputer riba dengan port Ethernet memberi perbandingan kedua yang mengeluarkan Wi-Fi sepenuhnya daripada gambaran. Jika terowong bertahan pada kedua-dua alternatif, rangkaian capaian asal patut diberi perhatian: perayauan antara titik capaian, penghala rumah yang jadual terjemahannya tamat tempoh, atau pautan huluan yang menetapkan semula aliran panjang.

Catat pemboleh ubah mana yang anda ubah. Perbandingan hanya dikira apabila segala-galanya kekal sama, dan itu termasuk titik akhir pelayan serta masa dalam hari.

Langkah tiga: petakan selang kepada lapisan

Panjang sesi yang baik ialah satu angka paling bermaklumat yang anda ada. Bacalah terhadap senarai ini sebelum menyentuh pemasa:

• Putusan selepas tidur atau sambung semula: keadaan terowong bertahan melalui penggantungan tetapi antara muka tidak. Periksa tingkah laku sambung semula klien apabila disambung semula dan sama ada perkhidmatan memulakan semula terowong atau menunggu trafik.
• Putusan hanya apabila melahu: sesuatu di tengah membiarkan aliran tamat tempoh. keepalive wujud untuk kes itu.
• Putusan pada usia sesi yang tetap: peristiwa pengesahan semula atau pembaharuan kunci, bukan kegagalan laluan. Penolakan jelas dalam log tepat pada selang itu ialah petunjuknya.
• Putusan semasa pemindahan besar atau halaman besar: syak MTU dan pemecahan, bukan pemasa melahu.

Untuk kes melahu, tetapan bergantung pada protokol dan kedua-dua hujung penting. keepalive 10 60 OpenVPN pada pelayan menghantar ping setiap 10 saat dan memulakan semula pautan selepas 60 saat tanpanya; klien WireGuard di belakang NAT menggunakan PersistentKeepalive = 25 dalam blok rakan. OpenVPN juga merunding semula saluran data mengikut pemasa, reneg-sec, yang secara lalai ialah 3600 saat dalam 2.x.

Jangan salin nilai agresif daripada panduan pembekal lain. Tamat masa pendek pada pautan mudah alih yang kerugian menghasilkan putusan yang sepatutnya dicegah, dan nilai yang ditolak pelayan mengatasi apa yang anda tetapkan dalam profil klien.

Langkah empat: bandingkan satu alternatif yang disokong

Jika pengendali menerbitkan profil UDP dan TCP, jalankan peranti dan rangkaian yang sama terhadap yang lain. Gunakan fail padanan sebenar dan bukan menyunting pengangkutan dalam profil salinan. Profil TCP yang stabil pada laluan yang UDP ditetapkan semula menyempitkan masalah kepada laluan itu; ia tidak membuktikan TCP ialah pengangkutan lebih baik di merata tempat.

Logik yang sama terpakai pada titik akhir. Cuba pelayan lain dan simpan hasil asal di sebelahnya. Jika hanya satu jalan keluar menetapkan semula sesi, itu bukti tentang titik akhir tersebut, bukan sebab untuk membina semula setiap penyesuai pada komputer riba.

Selepas apa-apa perubahan, ulangi pencetus asal dan sahkan ke mana trafik benar-benar pergi. Capaian internet yang pulih bukan hasil yang sama seperti trafik di dalam terowong, dan klien yang senyap jatuh kembali ke laluan langsung kelihatan sihat dari pelayar.

Sahkan pembaikan, dan kekalkan pengunduran

Pembaikan disahkan dengan menghasilkan semula pencetus asal, bukan dengan sambungan yang berjaya. Biarkan terowong melahu melepasi selang kegagalan lama, gantung dan sambung semula sekali, kemudian 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

Kekalkan profil sebelumnya dan nilai pemasa sebelumnya sehingga tingkah laku baharu bertahan sehari kerja penuh. Jika putusan kembali, pulihkan sandaran, kemudian gunakan semula perubahan satu demi satu supaya percubaan kedua bermula dari keadaan yang diketahui.

Jika log kekal bersih dan terowong masih terputus pada selang berulang, perhentian seterusnya ialah bahagian pelayan untuk sesi itu. Bawa pengecam sesi klien dan masa putusan yang tepat, kerana pasangan itulah yang menjadikan log pelayan boleh dicari. Pilihan pautan protokol didokumenkan dalam manual OpenVPN 2.6 apabila anda memerlukan makna tepat sesuatu nilai.