ESP keluar tanpa balasan bukan berarti VPN sudah mati
ESP melindungi satu arah per asosiasi dan tidak mengakui apa pun. Sejajarkan percakapan dalam dan SA masuk sebelum menyebut server tidak responsif.
Anda menangkap lalu lintas di host IPsec, melihat paket ESP keluar, tidak melihat apa pun kembali, dan menyimpulkan bahwa sisi jauh rusak. Tangkapan itu tidak mendukung kesimpulan tersebut. ESP melindungi satu arah percakapan dan tidak mengakui apa pun di lapisan IP, jadi tidak adanya ESP balik bisa sama mudahnya berarti aplikasi tidak punya apa-apa untuk dikatakan seperti berarti terowongan sudah mati. Baca pertukaran dalam dan keadaan sisi penerima sebelum menyalahkan salah satu ujung.
Mitos: setiap paket terlindungi berhak mendapat balasan
ESP bukan protokol permintaan-jawaban. Ia mengenkripsi dan mengautentikasi apa pun yang dipilih kebijakan, dan penerima memvalidasi, mendekripsi, dan mengirimkan paket dalam itu tanpa membuat paket sendiri. Kueri UDP yang diabaikan tujuan, atau gema ICMP yang dibuang kebijakan masuk, menghasilkan kesunyian di kedua arah sebagai hasil yang benar. Memperlakukan kesunyian itu sebagai kegagalan transportasi membuat Anda mencari kesalahan jaringan yang tidak pernah ada.
Yang benar-benar dibuktikan tangkapan satu arah adalah bahwa tumpukan pengirim mengenkripsi sesuatu pada titik pengamatan itu. Tidak ada apa pun tentang kedatangan, dan tidak ada apa pun tentang niat menjawab. Pertanyaan yang berguna bukan "mengapa tidak ada balasan" melainkan "apa yang seharusnya dihasilkan percakapan dalam".
Dua SA, dua SPI, satu percakapan
Asosiasi keamanan IPsec bersifat satu arah, jadi pertukaran terlindungi yang normal memiliki asosiasi masuk dan asosiasi keluar dengan pengenal terpisah dan keadaan independen. Mencari lalu lintas balik berdasarkan SPI paket keluar karena itu adalah kesalahan kategori, sebab balasan apa pun berjalan di bawah SA keluar milik rekan itu sendiri dengan SPI-nya sendiri. Cocokkan pasangannya melalui pemilih lalu lintas dan alamat rekan.
Pembaruan kunci mempersulit gambaran selama beberapa detik setiap kali, karena keadaan lama dan pengganti bisa tumpang tindih. Jika gejala dimulai di sekitar pembaruan kunci, kumpulkan pengenal asosiasi dan stempel waktu bersama-sama, bukan hanya nama koneksi.
Apa yang harus dilakukan penerima sebelum ada yang membalas
| Stage | What to look at | Wrong conclusion if skipped |
|---|---|---|
| Sender encrypts | outbound SA packet counter | "the tunnel is up" |
| Peer receives | inbound SA counter and replay window | "the peer is down" |
| Inner delivery | target host or service logs | "routing is broken" |
| Application replies | the app's own trace | "the reply was dropped" |
| Protected return | the peer's outbound SA | "ESP only works one way" |
Setiap baris gagal secara mandiri dan setiap kegagalan punya pemilik berbeda, itulah sebabnya satu tangkapan tidak bisa membedakannya. Penghitung masuk adalah satu-satunya bukti langsung kedatangan, karena paket yang gagal autentikasi atau pemeriksaan pengulangan dibuang tanpa respons apa pun. Rekan yang penghitung masuknya tidak bergerak karena itu tidak mengirimkan informasi apa pun tentang kebijakannya.
Pengiriman adalah langkah terpisah dari dekripsi. Keadaan bisa sah dan paket tetap dibuang sesudahnya oleh kebijakan masuk atau rute yang tidak mencakup tujuan dalam, jadi periksa apakah host tujuan melihat teks biasa alih-alih menganggap penghitung bersih berarti paket pergi ke tempat yang Anda inginkan.
ESP asli bukan UDP
ESP asli adalah protokol IP 50, yang bukan TCP maupun UDP dan sama sekali tidak punya port. Aturan firewall yang mengizinkan IKE pada UDP 500 karena itu tidak mengatakan apa pun tentang jalur data, dan filter yang ditulis seputar port bisa membiarkan terowongan bernegosiasi lalu membuang semua yang diangkut di dalamnya. Uji jalur data sendiri, dalam mode yang benar-benar Anda amati.
Di balik NAT bentuknya berubah: muatan terlindungi berjalan di dalam UDP, biasanya pada port 4500, sebagaimana RFC 3948 menetapkan. Catat mode aktif sebelum menulis aturan apa pun, karena perangkat di jalur bisa memperlakukan ESP asli dan ESP terbungkus UDP sepenuhnya berbeda, dan sebagian middlebox mengizinkan yang satu sambil membuang yang lain.
Baca penghitung yang termasuk insiden ini
Pada host strongSwan, swanctl --list-sas melaporkan penghitung paket dan bita per asosiasi di kedua arah, cukup untuk memisahkan "tidak pernah datang" dari "datang dan tidak dijawab". Di Linux, /proc/net/xfrm_stat menghitung kegagalan agregat seperti keadaan hilang, kebijakan hilang, dan galat protokol. Total itu menumpuk sejak boot dan milik satu ruang nama jaringan, jadi angka besar bukan atribusi.
Ambil dua pembacaan di sekitar jendela insiden di ruang nama yang benar dan bandingkan selisihnya, kalau tidak Anda akan menempelkan galat minggu lalu pada tiket sore ini. Tuliskan ruang nama dan kedua stempel waktu di tiket agar pembaca berikutnya bisa mereproduksi perbandingan alih-alih memercayai total.
Beri nama tahapnya, bukan tersangkanya
Kesimpulan yang berguna menyebut di mana paket berhenti: tidak pernah diterima, diterima dan dibuang, dikirim tetapi tidak dijawab, atau dijawab dan hilang di jalan pulang. Masing-masing menunjuk pada pemilik berbeda dan perintah berikutnya yang berbeda. "Tidak ada respons dari server VPN" meremas empat kegagalan berbeda menjadi satu kalimat yang tidak pernah dibenarkan tangkapan.
Jaga tangkapan tetap sempit, dan jaga keadaan kernel mentah di luar tiket, karena bisa membawa materi kunci yang tidak ada urusannya keluar dari host. Selisih penghitung dan stempel waktu adalah bagian yang layak diserahkan kepada orang berikutnya.