P_CONTROL_HARD_RESET_CLIENT_V2 di log: apakah ini kesalahan?

Baris itu berulang setiap beberapa detik dan tampak seperti penyebab segalanya: paket bernama control hard reset, yang datang dari klien yang tidak pernah sampai ke mana pun. Itu bukan kesalahan. Itu pesan pertama sebuah sesi baru, dan pengulangan adalah gejala dari hal lain yang gagal lebih jauh. Memisahkan apa yang dikatakan label dari apa yang dilakukan koneksi sesudahnya adalah seluruh diagnosis.

Opcode menamai posisi dalam protokol

OpenVPN memultipleks beberapa jenis paket di satu soket, dan opcode memberi tahu penerima jenis mana yang dipegangnya. Paket hard-reset membuka sesi, paket kontrol membawa materi handshake, pengakuan mengonfirmasi penerimaan, dan paket data membawa muatan terowongan. Membaca byte pertama menunjukkan di mana paket itu berada dalam pertukaran tersebut, dan definisi paket di kode sumber menamai setiap keluarga secara eksplisit.

Hanya itu yang dikatakannya. Paket yang diberi label sebagai reset awal klien membuktikan bahwa paket itu mencapai titik pengamatan Anda dan bahwa rekan ingin memulai sesi. Itu tidak membuktikan bahwa klien memercayai sertifikat Anda, bahwa kredensialnya diterima, atau bahwa kanal data pernah menjadi dapat digunakan.

Akhiran V2 adalah penanda generasi protokol untuk keluarga paket itu, bukan versi produk dan bukan pengaturan yang Anda pasang. Tidak ada apa pun dalam nama itu yang merujuk pada penyetelan ulang terowongan, memulai ulang layanan, atau membersihkan cache.

Apa yang sebenarnya dilakukan klien saat itu

Klien membuka pengenal sesi yang akan digunakan kedua pihak untuk lalu lintas kontrol berikutnya. Saat perlindungan kanal kontrol dikonfigurasi, paket pertama itu sudah membawa HMAC yang memungkinkan penerima memutuskan apakah akan mengeluarkan usaha untuk sisa pertukaran. Penerima yang tidak dapat memverifikasinya membuang paket itu diam-diam, itulah sebabnya kunci bersama yang salah tampak seperti klien yang berbicara ke kehampaan.

Belum ada hal yang terlihat pengguna terjadi. Tidak ada sertifikat yang divalidasi, tidak ada nama pengguna yang ditawarkan, dan tidak ada alamat terowongan yang diberikan. Reset adalah pembukaan handshake, jadi penilaian apa pun tentang koneksi pada titik ini terlalu dini.

Untuk lingkaran penyambungan ulang yang menganggur, detail yang menarik adalah intervalnya. Klien yang mencoba lagi dalam siklus tetap tanpa kemajuan biasanya ditolak sebelum dapat maju, dan alasannya ada di log rekan, bukan di nama paket.

Di mana kegagalan sebenarnya bersembunyi setelah reset

Baca kedua log berdampingan dan temukan peristiwa pertama yang bukan reset. Di klien, kegagalan validasi sertifikat dilaporkan dengan alasan yang spesifik: sertifikat kedaluwarsa, nama yang tidak cocok, atau penerbit yang tidak dikenal. Di server, penolakan kredensial dilaporkan sebagai kegagalan autentikasi dengan alasannya sendiri. Keduanya jauh lebih spesifik daripada pandangan berulang server tentang upaya baru.

Cocokkan satu upaya dengan stempel waktu alih-alih membaca setiap log secara terpisah, karena kegagalan yang sama muncul di kedua tempat dengan kata-kata dan tingkat keparahan berbeda. Rekan yang menyerah biasanya menyebutkan alasannya.

Jika tidak ada pihak yang melaporkan penolakan dan pertukaran tetap macet, batasnya adalah keterjangkauan, bukan kepercayaan. Firewall yang membuang arah balik, perangkat penerjemah alamat jaringan yang kedaluwarsa pemetaannya, atau masalah MTU yang mematikan paket handshake yang lebih besar semuanya menghasilkan pertukaran macet tanpa kesalahan autentikasi sama sekali.

grep -nE 'VERIFY|AUTH_FAILED|TLS Error|SIGUSR1' /var/log/openvpn*.log

Pencarian itu bukan diagnosis tersendiri, tetapi memindahkan Anda dari kosakata protokol ke kelas kegagalan yang sebenarnya dalam satu langkah.

Mengapa menonaktifkan verifikasi adalah refleks yang salah

Saat reset terus muncul, perbaikan yang tampak tercepat adalah menonaktifkan validasi sertifikat atau melepaskan perlindungan kanal kontrol agar sesuatu tersambung. Itu menukar kegagalan yang dapat didiagnosis dengan yang tidak dapat, dan membiarkan penerapan menerima rekan yang seharusnya ditolaknya.

Ubahlah batas yang benar-benar gagal. Masalah kepercayaan milik otoritas sertifikat dan profil yang merujuknya. Masalah waktu milik jam. Masalah kredensial milik backend autentikasi yang menolaknya, dan rekan yang tidak terjangkau milik jalur antara kedua host.

Opcode berguna dalam percakapan dukungan untuk satu hal: memberi tahu bahwa rekan sudah cukup jauh untuk mencoba. Apa yang terjadi setelah itu adalah yang perlu Anda ketahui, dan itu tercatat di log mana pun yang mencatat penolakan spesifik pertama. Mulai dari sana, dan baris reset berhenti tampak seperti penyebab dan mulai tampak seperti stempel waktu.