Tunnel VPN bersarang: mengapa yang dalam macet pada paket besar

DNS terselesaikan, sesi SSH tetap hidup, lalu unggahan besar membeku sementara ping ke host yang sama masih menjawab. Pemisahan itu menunjuk ke ukuran paket, bukan ke tunnel yang rusak. Tunnel bersarang mencapainya pada ukuran yang tidak akan dicapai salah satu tunnel sendirian. Sesi dalam baik-baik saja; ia hanya diberi paket yang tidak lagi muat.

Ke mana MTU jalur sebenarnya pergi

Setiap enkapsulasi menghabiskan byte sebelum lapisan berikutnya mendapat giliran. Jalur Ethernet menawarkan 1500 byte kepada paket luar, dan tunnel luar mengambil bagiannya sebelum apa pun di dalamnya bisa dialamatkan. Satu nilai overhead yang dikira-kira akan salah tepat sebesar jumlah yang penting.

Daftar lapisan secara berurutan: jalur akses, transport luar, tunnel luar, transport dalam, tunnel dalam, aplikasi. Hitung setiap header satu kali, dan pisahkan UDP dari header dan tag milik tunnel itu sendiri.

Dua lapisan WireGuard, dihitung sekali

Ambil jalur akses IPv4 dengan satu tunnel WireGuard di dalam yang lain. Lapisan luar memakan 20 byte IPv4, 8 byte UDP, dan 32 byte untuk header data WireGuard plus tag autentikasinya. Di dalamnya, tunnel dalam membutuhkan header IPv4 20 byte dan header UDP 8 byte miliknya sendiri sebelum 32 byte overhead WireGuard keduanya. Sisanya memuat header IPv4, header TCP, dan data. Jalur luar IPv6 memakan 40 alih-alih 20 dan menyisakan 1320.

Aritmetikanya berakhir di 1340 byte. Satu lapisan dengan aturan yang sama menyisakan 1400 untuk muatan TCP, yaitu 1500 dikurangi 20, 8, 32, 20, dan 20, dan selisih 60 byte itu persis enkapsulasi dalam yang ditambahkan tunnel kedua.

Terapkan 1400 pada jalur bersarang dan tunnel dalam kurang 60 byte, tak terlihat sampai sebuah paket cukup besar untuk membutuhkannya. Padding dan opsi fragmentasi milik protokol itu sendiri menggeser angka lagi, jadi percayai tabelnya.

MTU, MSS, dan fragmentasi bekerja di tempat berbeda

MTU antarmuka membatasi apa yang akan dikirim antarmuka, sedangkan penjepitan MSS TCP mengubah apa yang bersedia dikirim oleh rekan TCP. Penjepitan memperbaiki sesi TCP dan tidak melakukan apa pun untuk datagram UDP besar, itulah cara sebuah perbaikan tampak berhasil untuk satu aplikasi dan diam-diam melewatkan aplikasi berikutnya. Opsi fragmentasi milik protokol itu sendiri adalah tuas ketiga dengan kegagalannya sendiri. MTU antarmuka adalah langkah pertama yang umum dan yang paling kasar.

Tunnel berjembatan dan terutekan membawa frame berbeda, sehingga angka dari penerapan lain jarang ikut berlaku. Penemuan MTU jalur, yang dijelaskan dalam RFC 8201, hanya membantu selama pesan ICMP yang menjadi sandarannya diizinkan lewat.

Menemukan lapisan yang kurang

Verifikasi setiap tunnel sendiri-sendiri sebelum menyusunnya, jika persyaratan memungkinkan perbandingan. Probe berukuran tetap menyelesaikannya: ping -M do -s 1472 -c 3 10.8.0.1 mengirim paket IPv4 1500 byte penuh di dalam lapisan itu. Tambahkan lapisan kedua dan ulangi probe yang sama, sehingga kegagalan apa pun termasuk pada perubahan yang diketahui.

Saat transfer macet, ubah satu parameter terdokumentasi setiap kali dan catat ukuran yang gagal. Periksa juga jalur kembali, karena rekursi rute bersarang dapat meniru masalah ukuran paket cukup dekat hingga menghabiskan satu sore. Balasan ICMP yang disaring dapat menyembunyikan batas sebenarnya, jadi probe lebih penting daripada penalaran.

Tulis anggaran di tempat orang berikutnya akan menemukannya

Tabel dengan satu baris per lapisan bertahan lebih lama daripada aturan praktis. Simpan di samping diagram tunnel agar tidak ada yang mengulang aritmetikanya di bawah tekanan.

Lebih banyak tunnel berarti lebih banyak ketergantungan, jadi rencana rollback pantas mendapat tempatnya di samping anggaran. Jika angkanya masih tidak cocok, ukur jalurnya alih-alih menebak lagi. Tujuannya adalah angka yang bisa Anda pertahankan, bukan yang Anda hafal.