ESP keluar tanpa balasan tidak bermakna VPN sudah mati
ESP melindungi satu arah bagi setiap persatuan dan tidak mengesahkan apa-apa. Selaraskan perbualan dalaman dan SA masuk sebelum menyatakan pelayan tidak bertindak balas.
Anda merakam trafik pada hos IPsec, melihat paket ESP keluar, tidak melihat apa-apa kembali, dan membuat kesimpulan bahawa bahagian jauh rosak. Rakaman itu tidak menyokong kesimpulan tersebut. ESP melindungi satu arah perbualan dan tidak mengesahkan apa-apa pada lapisan IP, jadi ESP balasan yang tiada boleh bermakna aplikasi tidak mempunyai apa-apa untuk dikatakan sama seperti ia boleh bermakna terowong itu mati. Baca pertukaran dalaman dan keadaan bahagian penerima sebelum menyalahkan mana-mana hujung.
Mitos: setiap paket terlindung mendapat balasan
ESP bukan protokol permintaan-respons. Ia menyulitkan dan mengesahkan apa sahaja yang dipilih oleh dasar, dan penerima mengesahkan, menyahsulit dan menyampaikan paket dalaman itu tanpa menghasilkan paket sendiri. Pertanyaan UDP yang diabaikan oleh destinasi, atau gema ICMP yang dibuang oleh dasar masuk, menghasilkan kesenyapan dalam kedua-dua arah sebagai hasil yang betul. Menganggap kesenyapan itu sebagai kegagalan pengangkutan membawa anda mencari kerosakan rangkaian yang tidak pernah wujud.
Apa yang sebenarnya dibuktikan oleh rakaman sehala ialah tindanan pengirim menyulitkan sesuatu pada titik pemerhatian itu. Tiada apa-apa tentang ketibaan, dan tiada apa-apa tentang niat untuk menjawab. Soalan yang berguna bukanlah „mengapa tiada balasan“ tetapi „apa yang sepatutnya dihasilkan oleh perbualan dalaman“.
Dua SA, dua SPI, satu perbualan
Persatuan keselamatan IPsec adalah sehala, jadi pertukaran terlindung biasa menjalankan persatuan masuk dan persatuan keluar dengan pengecam berasingan dan keadaan bebas. Mencari trafik balasan untuk SPI paket keluar adalah kesilapan kategori, kerana sebarang balasan bergerak di bawah SA keluar rakan itu sendiri dengan SPI sendiri. Sebaliknya padankan pasangan itu mengikut pemilih trafik dan alamat rakan.
Pertukaran semula kunci merumitkan gambaran selama beberapa saat, kerana keadaan lama dan pengganti boleh bertindih. Jika gejala bermula sekitar pertukaran semula kunci, kumpulkan pengecam persatuan dan cap masa bersama-sama dan bukan hanya nama sambungan.
Apa yang penerima perlu lakukan sebelum apa-apa 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 bebas dan setiap kegagalan mempunyai pemilik berbeza, itulah sebabnya satu rakaman tidak dapat membezakannya. Pembilang masuk ialah satu-satunya bukti langsung ketibaan, kerana paket yang gagal pengesahan atau semakan ulangan dibuang tanpa sebarang respons. Rakan yang pembilang masuknya tidak bergerak tidak memberikan anda sebarang maklumat tentang dasarnya langsung.
Penghantaran ialah langkah berasingan daripada penyahsulitan. Keadaan boleh sah dan paket masih dibuang selepas itu oleh dasar masuk atau laluan yang tidak merangkumi destinasi dalaman, jadi periksa sama ada hos sasaran melihat teks biasa dan jangan andaikan pembilang bersih bermakna paket pergi ke tempat yang anda mahu.
ESP asli bukan UDP
ESP asli ialah protokol IP 50, yang bukan TCP atau UDP dan tidak mempunyai sebarang port. Oleh itu peraturan tembok api yang membenarkan IKE pada UDP 500 tidak mengatakan apa-apa tentang laluan data, dan penapis yang ditulis mengikut port boleh membenarkan terowong berunding dan kemudian menggugurkan semua yang dibawa di dalamnya. Uji laluan data secara berasingan, dalam mod yang anda benar-benar perhatikan.
Di belakang NAT bentuknya berubah: muatan terlindung bergerak di dalam UDP, biasanya pada port 4500, seperti yang ditakrifkan oleh RFC 3948. Rekodkan mod aktif sebelum menulis sebarang peraturan, kerana peranti di laluan boleh mengendalikan ESP asli dan ESP berkapsul UDP secara berbeza sama sekali, dan sesetengah kotak tengah membenarkan satu sambil menggugurkan yang lain.
Baca pembilang yang berkaitan dengan insiden ini
Pada hos strongSwan, swanctl --list-sas melaporkan pembilang paket dan bait bagi setiap persatuan dalam kedua-dua arah, yang cukup untuk memisahkan „tidak pernah tiba“ daripada „tiba dan tidak dijawab“. Pada Linux, /proc/net/xfrm_stat mengira kegagalan agregat seperti keadaan tiada, dasar tiada dan ralat protokol. Jumlah itu terkumpul sejak but dan tergolong dalam satu ruang nama rangkaian, jadi nombor besar bukan atribusi.
Ambil dua bacaan di sekitar tetingkap insiden dalam ruang nama yang betul dan bandingkan delta, jika tidak anda akan menempelkan ralat minggu lalu pada tiket petang ini. Letakkan ruang nama dan kedua-dua cap masa dalam tiket supaya pembaca seterusnya boleh menghasilkan semula perbandingan itu daripada mempercayai jumlah.
Namakan peringkat, bukan suspek
Kesimpulan yang berguna menyatakan di mana paket berhenti: tidak pernah diterima, diterima dan dibuang, dihantar tetapi tidak dijawab, atau dijawab dan hilang dalam perjalanan balik. Setiap satu menunjuk kepada pemilik berbeza dan arahan seterusnya yang berbeza. „Tiada respons daripada pelayan VPN“ meruntuhkan empat kerosakan berbeza menjadi satu ayat yang tidak pernah dibenarkan oleh rakaman.
Kekalkan rakaman sempit, dan jangan letakkan keadaan kernel mentah dalam tiket, kerana ia boleh membawa bahan kunci yang tidak sepatutnya meninggalkan hos. Delta pembilang dan cap masa ialah bahagian yang berharga untuk diserahkan kepada orang seterusnya.