Mengapa menyekat semua ICMP merosakkan laluan VPN yang berfungsi

Terowong yang berjaya disahkan, membawa ping dan kemudian tersekat pada pemindahan besar pertama ialah tanda klasik mesej ICMP yang hilang, bukan VPN yang rosak. Penghantar tidak pernah tahu paket itu terlalu besar, mengulang saiz yang sama, dan aplikasi menunggu. Membaikinya ialah keputusan dasar tembok api, bukan memasang semula klien. Urutan penting: ukur di mana sempadan saiz berada, kemudian sempitkan peraturan yang menelan laporan itu.

Apa yang ICMP sebenarnya bawa pada laluan ini

Penemuan MTU laluan IPv4 bergantung pada penghala yang melaporkan bahawa paket dengan bit don't-fragment tidak dapat diteruskan. Laporan itu ialah mesej ICMP Fragmentation Needed, dan tanpanya penghantar tiada sebab untuk mengurangkan saiz segmennya. IPv6 lebih ketat: penghala tidak memecahkan semasa transit, jadi mesej ICMPv6 Packet Too Big ialah satu-satunya isyarat yang membuat penghantar mengecil.

Kedua-dua mesej ialah maklum balas satah kawalan, dan kedua-duanya bukan gema diagnostik. Dasar yang menyekat ping dan dasar yang menyekat semua ICMP kelihatan serupa dalam senarai peraturan tetapi berkelakuan sangat berbeza di rangkaian. Yang kedua boleh mengubah terowong yang bersaiz betul menjadi laluan sehala untuk apa sahaja yang lebih besar daripada pautan terkecil dalam rantaian.

Sesetengah pengangkutan melaksanakan penemuan sendiri dengan paket siasatan, seperti yang diterangkan RFC 4821, dan ia kurang bergantung pada maklum balas ini. Itu hujah untuk menyemak pengangkutan mana yang anda jalankan, bukan untuk menganggap setiap terowong kebal.

Kegagalan bergantung pada saiz

Tanya sama ada kegagalan berkorelasi dengan saiz paket. Halaman log masuk, pertanyaan DNS dan panggilan API pendek berjaya, manakala muat naik fail, respons besar atau muat turun imej tersekat. Corak itu menunjuk kepada had saiz di suatu tempat antara kedua-dua hujung, bukan pengesahan atau penghalaan. Ping kecil yang berjaya hampir tidak mengatakan apa-apa tentang di mana sempadan itu berada.

Di dalam terowong ada dua lapisan yang perlu dipertimbangkan: paket muatan dan paket luar yang dikapsulkan. Penghantar dalaman boleh berkelakuan betul sementara laluan luaran lebih kecil daripada yang diandaikan terowong, itulah sebabnya tetapan MTU terowong itu sendiri dan pautan fizikal di bawahnya kedua-duanya penting.

Ukur sebelum menyunting peraturan

Uji dengan bit don't-fragment dan saiz muatan yang anda pilih, dari klien yang bermasalah ke arah alamat yang dilindungi:

ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7

Muatan 1472 bait ditambah 28 bait pengepala menjadi paket 1500 bait. Jika ujian besar gagal dengan ralat pemecahan dan yang kecil lulus, anda telah menemui sempadan; laraskan untuk overhed terowong dan ulangi sehingga saiz yang berfungsi stabil.

Kemudian sahkan bahawa jurang itu ialah laporan itu sendiri. Jika ujian gagal secara senyap, tanpa ralat dan tanpa balasan, mesej itu mungkin digugurkan dan bukan dihantar, dan peraturan itu ialah suspek.

Sempitkan peraturan, kemudian uji semula tugas itu

Pembetulan harus membenarkan mesej kawalan tertentu, bukan seluruh protokol. Pada hos iptables bentuknya ialah kebenaran khusus jenis; sesuaikan sintaks dengan apa yang menguruskan tembok api pada platform anda:

iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT

Biarkan balasan gema disekat jika itu dasar tempatan, kerana laluan tidak memerlukannya. Kemudian uji semula pemindahan yang pada asalnya gagal, dari sambungan baharu, dan sahkan bahawa pembilang peraturan menunjukkan mesej itu tiba.

Jika pemindahan besar masih tersekat selepas mesej dibenarkan, had yang tinggal ada di tempat lain: MTU terowong yang ditetapkan terlalu tinggi, proksi yang menulis semula paket, atau kotak perantaraan yang menggugurkan dan bukannya melaporkan. Peraturan ICMP itu perlu, bukan mencukupi.