Mitos MTU VPN: mengapa paket anda mengecil dan ke mana ruangnya pergi

Seseorang memberitahu anda bahawa VPN "kehilangan paket kerana MTU", anda menetapkan terowong kepada 1400, dan pemindahan berfungsi semula. Hasil itu terasa seperti diagnosis. Biasanya ia kebetulan aritmetik: anda memilih nombor yang cukup kecil untuk masuk di bawah had yang tidak pernah anda kenal pasti, dan anda akan bertemu had yang sama semula di rangkaian seterusnya dengan belanjawan yang berbeza.

Dua mitos menyebabkan sebahagian besar daripada ini. Yang pertama ialah MTU antara muka terowong ialah MTU laluan. Yang kedua ialah enkapsulasi berharga "satu tajuk" dan PPPoE tidak berharga apa-apa yang patut dikira. Kedua-duanya salah dengan cara yang membuatkan nombor yang anda pilih kelihatan sewenang-wenangnya sedangkan ia sebenarnya ditentukan.

Mitos satu: MTU terowong ialah MTU laluan

Nilai yang anda tetapkan pada antara muka terowong ialah janji tempatan tentang paket dalaman terbesar yang akan diserahkan oleh pelaksanaan ke bawah. Kapasiti sebenar laluan ialah sifat setiap pautan antara anda dan hujung jauh, dan ia boleh berubah apabila laluan berubah, apabila sambungan mudah alih diserahkan, atau apabila trafik mengambil peering lain. 1500 yang dikonfigurasikan memberitahu anda apa yang akan dibina oleh hos anda, bukan apa yang akan dibawa oleh rangkaian.

Penemuan MTU laluan wujud untuk menyelaraskan kedua-duanya, dan ia bergantung pada maklum balas. Dalam IPv4, penghala yang tidak dapat memajukan paket saiz penuh sepatutnya menghantar mesej ICMP "fragmentation needed", dan penghantar menurunkan anggarannya. Dalam IPv6, setaranya ialah mesej Packet Too Big, dan penghala tidak memecahkan langsung dalam transit. Apabila maklum balas itu ditapis, penghantar terus menghasilkan paket yang tidak dapat dibawa oleh laluan, dan tiada apa yang memberitahunya mengapa.

Mitos dua: enkapsulasi berharga satu tajuk

Kira lapisan luar dengan jujur. Tajuk IP luar ialah 20 bait dalam IPv4 atau 40 dalam IPv6. Enkapsulasi UDP untuk melintasi NAT menambah 8. Protokol terowong menambah tajuknya sendiri, vektor permulaan atau nonce, pengisi hingga sempadan blok atau penjajaran sifer, treler dan nilai semakan integriti. Bergantung pada protokol dan sifer, jumlahnya selesa dalam puluhan bait sebelum paket dalaman pun bermula.

Kemudian tolak semula tajuk paket dalaman itu sendiri. Segmen TCP di dalam terowong membawa tajuk IP 20 bait dan tajuk TCP 20 bait sendiri, dan MSS TCP diperoleh daripada MTU, bukan daripada muatan nominal terowong. Itulah sebabnya ping dengan muatan lebih kecil boleh berjaya sementara pemindahan fail tersekat: alat itu menguji perkara yang berbeza, dan hanya satu daripadanya menggunakan segmen TCP saiz penuh.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

Perintah pertama melaporkan MTU terowong yang dikonfigurasikan. Kedua-dua prob menghantar muatan 1472 bait, yang dengan 28 bait tajuk IPv4 dan ICMP ialah paket 1500 bait, kemudian yang lebih kecil. Jika prob besar gagal sepenuhnya dan yang kecil berjaya, anda mempunyai kerosakan yang bergantung pada saiz, bukan masalah penghalaan umum.

Mitos tiga: PPPoE masih memberi anda 1500 bersih

Pautan akses PPPoE konvensional tidak membawa paket IP 1500 bait. Tajuk PPPoE serta medan protokol PPP mengambil 8 bait di dalam bingkai Ethernet, yang meninggalkan 1492 untuk paket IP. Itulah had tradisional yang diterangkan dalam RFC 2516. Jika anda menjalankan VPN melalui pautan sedemikian, overhed terowong datang daripada 1492 itu, bukan daripada 1500.

RFC 4638 mentakrifkan cara untuk merundingkan muatan PPP yang lebih besar apabila kedua-dua pemusat akses dan peralatan pelanggan menyokongnya, sebab itu "sambungan ini menggunakan PPPoE" sahaja tidak membuktikan nombor tertentu. Tetapan tempatan tidak boleh memaksa peranti perantaraan menerima paket yang tidak pernah dikonfigurasikan untuknya, jadi soalan yang berguna ialah apa yang sebenarnya dirundingkan oleh pautan, bukan apa yang dikatakan label.

Mengapa kegagalan kelihatan terpilih

Permintaan kecil berjaya dan pemindahan besar tersekat ialah tandatangan klasik lubang hitam MTU laluan. Jabat tangan, pertanyaan DNS dan panggilan API semuanya muat; pemindahan pukal menghasilkan segmen saiz penuh yang mati pada satu pautan, dan mesej ICMP yang sepatutnya melaporkan masalah itu tidak pernah tiba. Sambungan kelihatan baik dan muat turun tergantung, yang membuatkan orang melihat pelayan dan bukannya laluan.

Kesilapan kedua yang berkaitan ialah mencampurkan tiga nombor: MTU antara muka, MSS TCP dan tetapan pemecahan atau pengisi protokol itu sendiri. Pengapit MSS pada penghala menulis semula MSS yang diiklankan supaya penghantar membina segmen yang lebih kecil; ia tidak mengubah MTU terowong, dan ia tidak membantu trafik UDP. Memberi ketiga-tiganya nombor yang sama kerana ia kelihatan berkaitan ialah cara perubahan berniat baik merosakkan persediaan yang berfungsi.

Apa yang perlu diubah, dan dalam urutan apa

Mulakan dengan bukti. Sahkan dengan prob di atas bahawa kerosakan bergantung pada saiz, kemudian cari saiz terkecil yang lulus dan terbesar yang gagal. Periksa MTU sebenar pautan akses sebelum menyalahkan terowong; pautan PPPoE mengehadkan belanjawan sebelum VPN anda menyentuhnya. Catat nilai asal supaya perubahan boleh dibatalkan.

Kemudian gunakan pelarasan terkecil yang didokumenkan oleh klien. Banyak klien menawarkan MTU terowong serta pilihan pembaikan MSS, dan pilihan MSS selalunya tuil yang lebih baik untuk TCP kerana ia sampai kepada penghantar tanpa mengecilkan setiap paket. Uji semula destinasi yang sama dan pemindahan yang sama, dan catat nombor yang anda tetapkan. Nilai terowong yang berfungsi pada satu rangkaian akses bukan pemalar sejagat, dan tapak seterusnya akan mempunyai belanjawannya sendiri.