Klien Anda melaporkan terhubung saat antarmuka menyala dan peramban kehabisan waktu, dan tidak satu pun dari ketiga pernyataan itu yang salah. Terhubung menggambarkan lapisan yang tidak ada hubungannya dengan halaman yang Anda minta. Menentukan lapisan mana yang melapor membutuhkan satu permintaan baru dan satu lihatan pada penghitung yang akan membuktikan lalu lintas berpindah. Mulai ulang membuang bukti itu dan membangun kembali kondisi yang Anda coba amati.

Tiga hal berbeda yang disebut terhubung

Di lapisan paling bawah, terhubung bisa berarti proses klien berjalan dan memegang soket menuju rekan. Di atasnya, itu bisa berarti ada antarmuka dengan alamat, yang bisa dibuat perangkat persisten atau rutin pemulihan tanpa sesi hidup di belakangnya. Di tingkat kendali, itu bisa berarti asosiasi telah dinegosiasikan, yang tidak mengatakan apa pun tentang apakah satu paket pun telah melintas di bawahnya. Masing-masing bertahan terhadap kegagalan yang tidak bertahan pada yang lain, dan klien biasanya menampilkan yang terkuat yang bisa diklaimnya.

Ikon hijau dan terowongan mati karena itu bersesuaian, bukan bertentangan; keduanya melaporkan objek yang berbeda. Itulah seluruh alasan kegagalan ini terus salah didiagnosis sebagai bug klien.

Kirim satu permintaan tak berbahaya ke tujuan yang benar-benar Anda butuhkan sebelum menyentuh daemon, dan biarkan blok lalu lintas langsung yang diwajibkan tetap di tempatnya selama Anda bekerja. Mulai ulang menghapus urutan peristiwa lalu menciptakannya kembali cukup dekat untuk menyembunyikan penyebabnya, dan itulah sebabnya tiket yang sama kembali seminggu kemudian tanpa sesuatu yang baru di dalamnya. Satu permintaan, satu pembacaan penghitung, dan pemicu yang menghasilkan kegagalan adalah bukti minimum.

Penghitung mana yang membuktikan paket berpindah

Dalam IPsec, asosiasi IKE dan asosiasi CHILD adalah objek terpisah, dan hanya child yang membawa penghitung yang menjawab pertanyaan ini. Daftar child, perhatikan apakah paket bertambah di kedua arah, dan bandingkan dengan apa yang coba dilakukan aplikasi. Asosiasi terpasang pada nol adalah temuan yang berbeda dari yang bertambah saat aplikasi masih gagal; yang pertama berarti lalu lintas tidak dipilih, yang kedua berarti lalu lintas bergerak dan kesalahannya lebih jauh. Baca penghitung dua kali, dengan jeda beberapa detik, karena satu sampel tidak bisa menunjukkan tren.

swanctl --list-sas
ip xfrm state list
ip -s link show dev tun0

Penghitung nol menunjuk pada pemilihan: perutean, kebijakan, ruang nama asal paket keluar, atau antarmuka yang tidak pernah diikat oleh klien. Penghitung yang tumbuh menunjuk menjauh dari terowongan, jadi lanjutkan dengan penerusan di ujung jauh, resolusi nama, jalur kembali, dan layanan tujuan, dalam urutan itu. Protokol tanpa objek child terpisah memaparkan bukti yang sama dalam istilahnya sendiri, jadi gunakan apa yang dilaporkannya tentang status rekan dan jumlah paket alih-alih meminjam kosakata IPsec. Bentuk pembacaan lebih penting daripada alat yang menghasilkannya.

Di mana kesalahan berada setelah penghitung bergerak

Gerbang yang menjawab pada alamat manajemennya sendiri membuktikan gerbang berjalan, bukan bahwa sesuatu di belakangnya melayani permintaan Anda, jadi uji sisi jauh, bukan kotak di tengah. Resolusi nama paling baik menyembunyikan kegagalan, karena resolver yang tidak bisa dijangkau lewat terowongan kehabisan waktu persis seperti koneksi mati. Dua pencarian memisahkan kasus itu, dan keduanya murah. Tanyakan dulu resolver yang didorong terowongan, lalu tanyakan resolver publik untuk nama yang sama.

dig +short host.example
dig +short @10.20.0.1 host.example
ping -c 2 10.20.0.25

Nama yang terurai lewat resolver publik tetapi tidak lewat resolver terowongan berarti jalur DNS rusak, sedangkan nama yang terurai lewat keduanya dan tetap kehabisan waktu di peramban menunjuk pada jalur kembali atau pada layanan. Jika ping berdasarkan alamat berhasil dan aplikasi tetap menolak, jaringan telah mengantarkan permintaan dan layanan menolaknya, yang merupakan tahap yang jauh lebih akhir.

Catat pemicunya, lalu ubah satu hal

Catat apa yang mendahului kegagalan: rentang diam, perubahan jaringan, pembaruan kunci, laptop yang dilanjutkan, atau sistem yang dipulihkan. Semuanya menghasilkan mekanisme berbeda, dan biasanya hanya sistem yang dipulihkan memperbaiki dirinya sendiri, yang justru merupakan kasus yang tidak mengajarkan apa pun kepada Anda. Mulai ulang menghapus urutan peristiwa lalu menciptakan kembali kondisi yang cukup dekat untuk menyembunyikan penyebabnya. Tuliskan pemicunya selama masih bisa direproduksi.

Lalu lakukan satu koreksi yang didukung dan ulangi permintaan asli bersama pemicu yang menghasilkan kegagalan. Diam adalah pemicu yang paling mudah direproduksi, jadi itu konfirmasi tercepat bahwa perbaikan menangani mekanismenya, bukan gejalanya.

Yang ingin Anda laporkan adalah bukti bahwa lalu lintas yang hendak Anda kirim telah mencapai layanan yang hendak Anda tuju. Ikon yang berubah hijau, halaman tersimpan di tembolok yang dimuat, dan penghitung yang bergerak semuanya membuktikan kurang dari satu permintaan tuntas ke tujuan yang dimaksud. Simpan permintaan, pembacaan penghitung, dan pemicu bersama-sama, agar orang berikutnya bisa membedakan perbaikan dari kebetulan.

Artikel terkait