Ping bukan bukti: uji jalur antara dua lokasi

Tunelnya aktif, gateway saling menjawab, dan pengguna di satu lokasi tetap tidak bisa membuka berbagi berkas di lokasi lain. Seseorang melakukan ping dari gateway, mendapat balasan, dan menyatakan jaringan sehat. Balasan itu menempuh perjalanan antara dua perangkat yang tidak pernah menjadi masalah. Uji yang berguna dimulai dari host yang membutuhkan layanan, memakai protokol yang dipakai aplikasi, dan mereproduksi kondisi yang membuatnya gagal. Semua yang lain adalah lampu hijau bagi jalur yang tidak dilewati siapa pun.

Mulai dari klien yang membutuhkan layanan

Catat empat hal sebelum menguji apa pun: alamat klien, alamat tujuan, nama host, dan porta aplikasi. Lalu pastikan layanan berfungsi secara lokal di lokasinya sendiri, dari host di sebelahnya. Tanpa garis dasar itu Anda tidak bisa membedakan tunel rusak dari layanan rusak, dan separuh tiket ini adalah yang kedua.

Coba nama host yang didokumentasikan dan, jika layanan mengizinkannya, pemeriksaan alamat langsung pada porta yang sama. Pencarian nama yang gagal dan alamat hasil resolusi yang tak terjangkau membawa Anda ke jalur berbeda. Jika Anda mengganti nama host dengan IP, jangan nonaktifkan pemeriksaan identitas HTTPS agar berfungsi; peringatan sertifikat adalah informasi, bukan hambatan.

Telusuri jalur di setiap tepi

Baca rute yang dipilih klien, lalu rute yang dipilih gateway untuk tujuan itu, lalu penghitung atau tangkapan terbatas di setiap tepi. Anda mencari dua fakta: apakah permintaan sampai ke LAN jauh, dan apakah balasan kembali. Penghitung antarmuka mencakup setiap aliran lain, jadi korelasikan berdasarkan stempel waktu tepat dan pasangan alamat, bukan berdasarkan bentuk grafik. Tangkapan di tepi yang salah lebih buruk daripada tidak ada, karena tampak seperti bukti.

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

Jika permintaan muncul di tepi jauh tanpa balasan di belakangnya, masalahnya ada di sisi seberang: firewall, rute balik yang hilang, atau host yang tidak menerima sumber. Jika permintaan tidak pernah muncul, rute lokal atau pemilih tunel tidak membawanya, dan sisi seberang belum layak diselidiki.

Gunakan protokol yang dipakai aplikasi

ICMP adalah pemeriksaan yang lemah. Ia bisa difilter, dibatasi lajunya, atau ditangani kebijakan yang berbeda dari layanan, sehingga keberhasilan dan kegagalannya sama-sama ambigu. Uji porta sebenarnya dan, bila bisa, jabat tangan protokol yang sebenarnya.

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

Jabat tangan TCP yang selesai membuktikan keterjangkauan dan kebijakan untuk porta itu. Itu tidak membuktikan aplikasi berfungsi: autentikasi, unggahan, atau panggilan API tertentu masih bisa gagal. Uji operasi yang benar-benar dilakukan pengguna, dengan padanan yang tidak berbahaya alih-alih berulang kali mengirim transaksi nyata.

Reproduksi kondisi yang gagal

Kegagalan yang hanya muncul pada transfer besar adalah masalah ukuran, bukan konektivitas. Kirim paket besar dengan bit don't-fragment diaktifkan dan perhatikan di mana ia berhenti. Jika permintaan kecil berhasil dan yang besar menggantung, MTU tunel dan penanganan MSS di gateway adalah tersangka berikutnya.

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

Jika hanya satu subnet gagal, periksa pemilih lalu lintas, pengumuman rute, dan gateway balik subnet itu. Jika hanya nama host yang gagal, ikuti DNS, termasuk resolver mana yang dipakai klien dan apakah tampilan jauh terlihat dari lokasi itu. Tiga kegagalan berbeda, tiga perbaikan berbeda, dan uji ping tidak membedakan satu pun.

Setelah perbaikan, ulangi uji yang sama

Jalankan lagi klien, tujuan, porta, dan muatan yang identik. Lalu sambungkan ulang atau uji jalur failover jika desainnya punya, karena perbaikan yang hanya berfungsi selama instans tunel asli hidup belum diuji. Kaitkan uji pada sumber nyata, tujuan nyata, dan operasi nyata alih-alih satu indikator hijau di dasbor.

Catat empat nilai dasar dan hasilnya. Laporan berikutnya tentang gejala yang sama kemudian bisa dimulai dari bukti, bukan dari ping.