Paket IPv6 terlalu besar: mengapa transfer VPN besar macet

Ping berfungsi, peramban memuat halaman kecil, dan transfer berkas macet, semuanya lewat IPv6 melalui terowongan yang sama. Pola itu biasanya berarti pengirim tidak pernah mempelajari ukuran jalur yang sebenarnya, bukan bahwa terowongan lambat. IPv6 mengharapkan perute mengabarkan masalahnya dengan pesan Packet Too Big, dan enkapsulasi menambah beban sebelum paket mencapai jaringan luar. Jika pesan itu disaring, pengirim terus mengulang ukuran yang tidak bisa lewat.

Permintaan kecil, kemacetan besar

Terowongan membungkus setiap paket dalam tajuk lain, jadi ukuran yang dapat dipakai di dalam lebih kecil daripada ukuran di luar. Paket yang diukur untuk tautan fisik sebelum enkapsulasi menjadi terlalu besar sesudahnya. Perute IPv4 boleh memecah di jalur, sedangkan perute IPv6 tidak melakukannya atas nama pengirim, jadi pengirim harus menyesuaikan diri. Dan penyesuaian itu sepenuhnya bergantung pada diterimanya umpan balik.

Satu pesan yang hilang cukup untuk memunculkan gejala klasik: jabat tangan dan balasan kecil berhasil, sedangkan daftar direktori atau unggahan macet di titik yang sama setiap kali. Pengguna menyebutnya VPN lambat, dan log tidak menunjukkan kesalahan apa pun pada autentikasi. Kedua pengamatan akurat, dan tidak satu pun menemukan letak gangguannya.

Packet Too Big adalah umpan balik, bukan lalu lintas

Pesan ICMPv6 Packet Too Big membawa ukuran yang dapat diterima lompatan berikutnya, dan pengirim memakainya untuk menurunkan perkiraannya. Menyaringnya sama dengan mencabut rambu jalan lalu menyalahkan pengemudi. Aturan yang membuang semua ICMPv6 tampak ketat sekaligus merusak penemuan jalur pada setiap tautan yang membutuhkannya. Pesan itu informasi kendali tentang jalur, bukan muatan aplikasi.

Penyaringan selektif tetap masuk akal. Permintaan gema dan penemuan tetangga berperan berbeda dari pesan galat, dan kebijakan dapat memperlakukannya secara berbeda. Ikuti panduan penyaringan terdokumentasi platform alih-alih menerima atau membuang seluruh protokol, karena RFC 8201 menentukan bagaimana umpan balik itu menggerakkan penemuan.

Uji kedua keluarga alamat secara terpisah

Uji IPv6 secara terpisah, karena transfer IPv4 yang berhasil tidak membuktikan apa pun tentang jalur IPv6. Lalu tangkap pesan kendali saat transfer besar macet. Kedua rekaman itu bersama-sama menunjukkan umpan balik keluar, atau membuktikan bahwa pesan itu tidak pernah tiba.

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

Probe mengirim paket dengan bit do-not-fragment disetel dan melaporkan ukuran tempat ia gagal, yaitu angka yang harus ditampung terowongan. Kueri rute menyebut antarmuka yang akan membawa tujuan, sehingga Anda tahu MTU tautan mana yang berlaku. Penangkapan menyaring ICMPv6 tipe 2, pesan Packet Too Big, dan menunjukkan apakah pesan itu mencapai host ini. Jika pesan muncul di tangkapan dan transfer tetap macet, pengirim mengabaikannya, yang memindahkan penyelidikan ke tumpukan alih-alih ke jaringan.

Ubah ukuran terowongan hanya setelah bukti

Menurunkan MTU terowongan dapat menyembunyikan pesan yang tersaring dan menghilangkan gejalanya, dengan biaya beban lebih besar pada setiap paket. Itu jalan pintas, bukan diagnosis, dan semestinya menyusul tangkapan, bukan menggantikannya. Nilai rendah sembarangan juga tidak merusak apa pun secara kasatmata, itulah sebabnya ia bertahan bertahun-tahun dalam konfigurasi. Ubahlah dengan sengaja, catat nilainya, dan tuliskan pengukuran mana yang membenarkannya.

Bila Anda mengendalikan gerbang, periksa aturan yang membuang pesan itu alih-alih mematikan firewall. Satu aturan yang diperbaiki lebih sempit daripada pengecualian kebijakan dan jauh lebih mudah dipertahankan nanti. Alasan yang sama berlaku untuk batas waktu: tidak setiap kemacetan adalah masalah ukuran, dan tangkapanlah yang memisahkan keduanya.