Mengapa memblokir seluruh ICMP merusak jalur VPN yang berfungsi

Tunnel yang berhasil diautentikasi, membawa ping, lalu macet pada transfer besar pertama adalah tanda klasik pesan ICMP yang hilang, bukan VPN yang rusak. Pengirim tidak pernah tahu bahwa paket terlalu besar, terus mengulang ukuran yang sama, dan aplikasi menunggu. Memperbaikinya adalah keputusan kebijakan firewall, bukan memasang ulang klien. Urutannya penting: ukur di mana batas ukuran berada, lalu persempit aturan yang menelan laporan itu.

Apa yang sebenarnya dibawa ICMP di jalur ini

Penemuan MTU jalur IPv4 bergantung pada router yang melaporkan bahwa paket dengan bit don't-fragment tidak dapat diteruskan. Laporan itu adalah pesan ICMP Fragmentation Needed, dan tanpanya pengirim tidak punya alasan memperkecil ukuran segmennya. IPv6 lebih ketat: router tidak memfragmentasi di jalur transit, jadi pesan ICMPv6 Packet Too Big adalah satu-satunya sinyal yang membuat pengirim mengecil.

Kedua pesan adalah umpan balik bidang kendali, dan tidak satu pun merupakan gema diagnostik. Kebijakan yang memblokir ping dan kebijakan yang memblokir semua ICMP terlihat serupa dalam daftar aturan tetapi berperilaku sangat berbeda di jaringan. Yang kedua dapat mengubah tunnel berukuran benar menjadi jalur satu arah untuk apa pun yang lebih besar dari tautan terkecil dalam rantai.

Beberapa transport mengimplementasikan penemuan sendiri dengan paket probe, seperti yang dijelaskan RFC 4821, dan itu kurang bergantung pada umpan balik ini. Itu argumen untuk memeriksa transport mana yang Anda jalankan, bukan untuk menganggap setiap tunnel kebal.

Kegagalan bergantung pada ukuran

Tanyakan apakah kegagalan berkorelasi dengan ukuran paket. Halaman masuk, kueri DNS, dan panggilan API singkat berhasil, sementara unggahan berkas, respons besar, atau unduhan gambar macet. Pola itu menunjuk ke batas ukuran di suatu tempat antara kedua ujung, bukan ke autentikasi atau perutean. Ping kecil yang berhasil hampir tidak mengatakan apa pun tentang di mana batas itu berada.

Di dalam tunnel ada dua lapisan yang perlu dipertimbangkan: paket muatan dan paket terenkapsulasi luar. Pengirim dalam dapat berperilaku benar sementara jalur luar lebih kecil daripada yang diasumsikan tunnel, itulah sebabnya pengaturan MTU tunnel itu sendiri dan tautan fisik di bawahnya sama-sama penting.

Ukur sebelum menyunting aturan

Uji dengan bit don't-fragment dan ukuran muatan yang Anda pilih, dari klien yang bermasalah menuju alamat yang dilindungi:

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

Muatan 1472 byte ditambah 28 byte header menjadi paket 1500 byte. Jika probe besar gagal dengan kesalahan fragmentasi dan yang kecil lolos, Anda telah menemukan batasnya; sesuaikan dengan overhead tunnel dan ulangi sampai ukuran yang berfungsi stabil.

Lalu pastikan celahnya adalah laporan itu sendiri. Jika probe gagal secara diam-diam, tanpa kesalahan dan tanpa balasan, pesan itu kemungkinan dibuang, bukan dikirim, dan aturannya adalah tersangkanya.

Persempit aturan, lalu uji ulang tugasnya

Perbaikan harus mengizinkan pesan kendali tertentu, bukan seluruh protokol. Pada host iptables bentuknya adalah penerimaan khusus tipe; sesuaikan sintaksisnya dengan apa yang mengelola firewall di 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 tetap diblokir jika itu kebijakan lokal, karena jalur tidak membutuhkannya. Lalu uji ulang transfer yang semula gagal, dari koneksi baru, dan pastikan penghitung aturan menunjukkan pesan-pesan itu tiba.

Jika transfer besar masih macet setelah pesan diizinkan, batas yang tersisa ada di tempat lain: MTU tunnel yang disetel terlalu tinggi, proxy yang menulis ulang paket, atau kotak perantara yang membuang alih-alih melaporkan. Aturan ICMP itu perlu, bukan cukup.