Paket IPv6 terlalu besar: mengapa pemindahan VPN besar tersekat

Ping berfungsi, pelayar memuatkan halaman kecil dan pemindahan fail tersekat, semuanya melalui IPv6 dalam terowong yang sama. Corak ini biasanya bermaksud penghantar tidak pernah mempelajari saiz laluan yang sebenar, bukan kerana terowong itu perlahan. IPv6 menjangkakan penghala melaporkan masalah dengan mesej Packet Too Big, dan enkapsulasi menambah beban sebelum paket sampai ke rangkaian luar. Jika mesej itu ditapis, penghantar terus mengulang saiz yang tidak dapat melepasi.

Permintaan kecil, tersekat besar

Terowong membalut setiap paket dalam pengepala lain, jadi saiz yang boleh digunakan di dalam lebih kecil daripada saiz di luar. Paket yang disaizkan untuk pautan fizikal sebelum enkapsulasi menjadi terlalu besar selepasnya. Penghala IPv4 boleh memecahkan di laluan, manakala penghala IPv6 tidak melakukannya bagi pihak penghantar, jadi penghantar perlu menyesuaikan diri sendiri. Dan penyesuaian itu bergantung sepenuhnya pada penerimaan maklum balas.

Satu mesej yang hilang sudah cukup untuk menghasilkan gejala klasik: jabat tangan dan balasan kecil berjaya, dan senarai direktori atau muat naik tersekat pada titik yang sama setiap kali. Pengguna menyifatkannya sebagai VPN perlahan, dan log tidak menunjukkan apa-apa yang salah pada pengesahan. Kedua-dua pemerhatian tepat dan tiada satu pun menemui lokasi kerosakan.

Packet Too Big ialah maklum balas, bukan trafik

Mesej ICMPv6 Packet Too Big membawa saiz yang boleh diterima oleh lompatan seterusnya, dan penghantar menggunakannya untuk menurunkan anggarannya. Menapisnya sama seperti menanggalkan papan tanda jalan dan kemudian menyalahkan pemandu. Peraturan yang membuang semua ICMPv6 kelihatan ketat tetapi memecahkan penemuan laluan pada setiap pautan yang memerlukannya. Mesej itu ialah maklumat kawalan tentang laluan, bukan muatan aplikasi.

Penapisan terpilih masih wajar. Permintaan gema dan penemuan jiran memainkan peranan berbeza daripada mesej ralat, dan dasar boleh melayaninya secara berbeza. Ikuti panduan penapisan platform yang didokumenkan dan bukannya menerima atau membuang seluruh protokol, kerana RFC 8201 menentukan bagaimana maklum balas itu memacu penemuan.

Uji kedua-dua keluarga alamat secara berasingan

Uji IPv6 secara berasingan, kerana pemindahan IPv4 yang berjaya tidak membuktikan apa-apa tentang laluan IPv6. Kemudian tangkap mesej kawalan semasa pemindahan besar tersekat. Kedua-dua rekod bersama-sama sama ada menunjukkan maklum balas keluar atau membuktikan ia 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'

Prob menghantar paket dengan bit do-not-fragment ditetapkan dan melaporkan saiz di mana ia gagal, iaitu nombor yang terowong harus tampung. Pertanyaan laluan menamakan antara muka yang akan membawa destinasi, jadi anda tahu MTU pautan mana yang terpakai. Tangkapan menapis ICMPv6 jenis 2, mesej Packet Too Big, dan menunjukkan sama ada ia sampai ke hos ini. Jika mesej muncul dalam tangkapan dan pemindahan masih tersekat, penghantar mengabaikannya, yang memindahkan siasatan ke timbunan dan bukannya rangkaian.

Ubah saiz terowong hanya selepas bukti

Menurunkan MTU terowong boleh menyembunyikan mesej yang ditapis dan menghilangkan gejala, dengan kos beban yang lebih tinggi pada setiap paket. Ia jalan pintas dan bukan diagnosis, dan ia patut menyusuli tangkapan dan bukannya menggantikannya. Nilai rendah sewenang-wenangnya juga tidak merosakkan apa-apa yang kelihatan, sebab itulah ia bertahan bertahun-tahun dalam konfigurasi. Ubahnya dengan sengaja, catat nilainya, dan nyatakan ukuran mana yang membenarkannya.

Apabila anda mengawal get laluan, periksa peraturan yang membuang mesej itu dan bukannya mematikan tembok api. Satu peraturan yang diperbetulkan lebih sempit daripada pengecualian dasar dan jauh lebih mudah dipertahankan kemudian. Penaakulan yang sama terpakai pada tamat masa: bukan setiap tersekat masalah saiz, dan tangkapan itulah yang memisahkan kedua-duanya.