Waktu habis koneksi VPN: DNS, transport, negosiasi, atau login

“Koneksi habis waktu” adalah galat paling tidak spesifik yang bisa dicetak klien VPN. Artinya satu operasi melewati tenggatnya, dan setiap tahap dari resolusi nama hingga balasan login punya tenggat. Klien yang hanya menampilkan pesan akhir membuat tahap-tahap tampak identik, sehingga orang menaikkan batas waktu, mengganti port, dan memasang ulang profil, dalam urutan itu, tanpa belajar apa pun. Membandingkan tahap-tahap lebih cepat: masing-masing gagal di tempat berbeda, dan setiap kegagalan meninggalkan jenis bukti berbeda.

Empat tahap, empat kegagalan berbeda

Urutannya tetap bahkan ketika klien menyembunyikannya: nama harus diresolusi, transport harus dibuat ke alamat hasilnya, protokol harus menegosiasikan parameter dan kuncinya, dan akun harus diautentikasi. Panduan pemecahan masalah konektivitas OpenVPN mengikuti urutan yang sama untuk kliennya sendiri, dan yang lain mengikutinya dengan dekat. Waktu habis di tahap dua dan waktu habis di tahap empat tidak punya kesamaan selain kata di layar.

Bacalah log untuk baris terakhir yang menunjukkan kemajuan, bukan baris terakhir sebelum galat. Sebagian besar klien mencetak sesuatu seperti alamat yang diresolusi, soket yang terbentuk, handshake yang dimulai, atau permintaan autentikasi, dan tahap setelah baris itu adalah yang habis waktu.

Resolusi nama gagal sebelum apa pun dihubungi

Jika titik akhir tidak pernah diresolusi, klien tidak punya apa pun untuk dihubungi dan tidak ada pekerjaan transport yang terjadi. Kegagalan itu biasanya seketika, bukan waktu habis penuh, dan itulah cara termurah membedakannya dari yang lain. Uji nama dengan resolver sistem dan dengan resolver kedua, lalu bandingkan kedua jawaban sebelum menyimpulkan server mati.

Alamat lama yang disalin dari posting forum adalah penyebab umum waktu habis yang tampak seperti masalah server, karena alamat itu sekarang milik sesuatu yang lain atau tidak milik apa pun. Gunakan profil operator yang sekarang, bukan mengganti dengan alamat yang dulu berfungsi. Tidak adanya balasan ping bukan bukti ke arah mana pun: banyak titik akhir membuang ICMP sementara melayani dengan sangat baik.

Penyiapan transport menunggu paket yang tidak akan datang

Ketika DNS baik dan klien tetap menghabiskan seluruh batas waktu, lapisan transport adalah tersangkanya. Pada TCP Anda bisa menguji port langsung; Test-NetConnection di Windows atau nc -vz di Linux memberi tahu apakah sesuatu menerima koneksi, dan itu lebih berguna daripada ping. Pada UDP Anda tidak bisa menguji dengan cara yang sama, karena tidak ada handshake untuk diselesaikan di lapisan itu, dan asimetri ini menimbulkan banyak kesimpulan keliru.

Yang dibuktikan uji TCP terbatas: layanan yang menerima port 443 belum tentu pendengar VPN, dan titik akhir khusus UDP tidak punya port TCP untuk menerima apa pun. Menulis ulang profil dari UDP ke TCP tidak membuat pendengar di sisi lain; itu hanya mengubah apa yang ditunggu klien Anda. Jika jaringan memfilter protokolnya, perubahan itu menghasilkan waktu habis berbeda pada tahap yang sama.

Portal captive layak mendapat pemeriksaan sendiri pada tahap ini. Sampai portal mengotorisasi perangkat, lalu lintas keluar menuju portal dan upaya terowongan sekadar menggantung. Selesaikan portal di peramban dahulu, lalu coba lagi, dan jangan ubah profil selama portal masih tertunda.

Negosiasi dan login berarti server menjawab

Begitu terowongan mencapai server, klien memulai handshake dan galat berubah sifat. Kemacetan di sini soal kompatibilitas, bukan keterjangkauan: versi protokol tidak cocok, pengaturan cipher atau kanal data yang tidak akan diterima sisi lain, atau profil yang mengharapkan fitur yang tidak ditawarkan server. OpenVPN memindahkan nilai bawaan negosiasinya antarversi utama cukup sering sehingga profil yang ditulis untuk satu generasi bisa mencapai server dan tetap gagal naik.

Autentikasi adalah tahap terakhir dan paling mudah salah dibaca. Penolakan eksplisit adalah jawaban, yang berarti jalurnya bekerja dan masalahnya ada pada identitas, sertifikat, atau keadaan akun. Alur masuk tunggal berbasis peramban adalah kasus ketiga: klien menunggu tindakan yang belum Anda lakukan, atau peramban yang tidak bisa diluncurkan, dan tidak ada yang akan datang sampai Anda menyelesaikan langkah itu.

Bandingkan buktinya sebelum mengubah percobaan ulang

Jaga perangkat dan profil tetap dan ubah satu hal setiap kali, dimulai dari jaringan. Jika profil yang sama terhubung di hotspot ponsel dan habis waktu di Wi-Fi hotel, variabelnya adalah jalur, bukan server. Jika gagal di mana-mana, variabelnya adalah profil atau titik akhir. Jika hanya gagal pada satu waktu tertentu, catat stempel waktunya dan bandingkan dengan peristiwa sisi server sebelum berasumsi apa pun tentang beban.

Untuk layanan yang Anda kelola, perbandingan yang menentukan adalah apakah upaya itu tiba sama sekali. Koneksi yang mencapai pendengar lalu macet termasuk tahap negosiasi; yang tidak pernah muncul di pandangan pendengar adalah masalah transport atau resolusi, dan tidak ada penyetelan percobaan ulang yang akan menggesernya. Log server juga memisahkan login yang ditolak dari penurunan senyap, yaitu perbedaan antara perbaikan identitas dan perbaikan firewall.

Catat versi klien, nama profil, waktu upaya beserta zona waktunya, dan galat pertama yang berguna alih-alih baris terputus terakhir. Hapus kunci dan materi yang memuat kredensial sebelum membagikan kutipannya. Lalu lakukan satu koreksi bermakna dan coba lagi, karena tenggat lebih panjang hanya membantu operasi lambat yang terdokumentasi dan tidak melakukan apa pun untuk alamat salah atau port yang diblokir.