IPIP di dalam WireGuard: 20 byte ekstra yang tidak dianggarkan siapa pun

Ping kecil melintasi tunnel sepanjang hari, banner SSH tiba, lalu sesi membeku tepat saat transfer file dimulai. Pola itu menunjuk pada anggaran byte yang dihitung di lapisan yang salah, di mana tunnel luar diukur untuk overhead-nya sendiri dan tidak ada yang mengurangi tunnel dalam. Paket IPIP bersarang hanyalah paket IP lain bagi WireGuard, dan itulah sebabnya ia memakai byte yang tidak pernah Anda sisihkan. Koreksinya adalah aritmetika, dan muat dalam tiga perintah dan satu tabel.

Gejala yang membocorkannya

Masalah fragmentasi mengumumkan dirinya melalui ukuran, tidak pernah melalui alamat. Peer Anda menjawab ping 56 byte selama satu jam lalu diam pada 1400 byte sementara tunnel tetap naik dan tidak ada rute yang berubah. Handshake masuk, jendela TCP penuh pertama tidak, dan transfer tersendat beberapa detik setelah tampak sehat.

Ukur plafon sebelum Anda mengedit apa pun, karena plafon yang tidak diukur adalah yang akan Anda kejar dua kali. Kirim satu probe di bawah ukuran yang dicurigai dengan bit do-not-fragment disetel, ping -M do -s 1000 10.9.0.2, lalu ulangi pada ukuran yang sudah Anda tahu terlalu besar. Saat pembalikan mengikuti ukuran payload sementara tujuan tetap tidak berubah, perutean menjalankan tugasnya dan ada satu header yang hilang dari anggaran.

Hitung setiap header satu kali, di lapisan yang benar

Mulailah dari MTU terkecil di jalur, bukan dari antarmuka tunnel, karena dinding berada di hulu kedua ujung. WireGuard menghabiskan 60 byte untuk transport luar IPv4: 20 untuk IP, 8 untuk UDP, dan 32 untuk header-nya sendiri, dan 80 byte saat transport itu IPv6. wg0 1420 byte menyimpan 20 byte kelonggaran di bawah 1440 yang benar-benar dapat dikirim jalur 1500 byte, dan itulah sebabnya angka yang disalin dari wiki masih cocok di sini. Gambarkan seluruh tumpukan pada diagram, karena siapa pun yang mengubah MTU berikutnya jika tidak akan memilih angka bulat baru dan mewarisi bug Anda.

Baris kelima adalah tempat anggaran salah, karena 1400 byte yang dibawa antarmuka bersarang sudah mencakup 40 byte header milik paket asli. Hanya 1360 dari byte itu yang mencapai proses yang membaca file. Perlakukan 1400 sebagai payload aplikasi, seperti yang diundang setiap diagram tanpa kolom itu, dan perangkat dalam berakhir 40 byte terlalu murah hati terhadap dinding yang tidak bergerak.

Atur kedua MTU secara terpisah

Pembawa dan perangkat bersarang adalah objek terpisah, jadi masing-masing memerlukan nilainya sendiri. Terapkan dalam urutan ini, karena perangkat bersarang tidak mewarisi apa pun dari pembawa:

ip link set wg0 mtu 1420
ip tunnel add ipip0 mode ipip remote 203.0.113.9 local 198.51.100.4
ip link set ipip0 mtu 1400

Aturan yang layak dihafal: MTU dalam = MTU luar - 20 saat paket yang dibawa tunnel IPIP adalah IPv4, dan - 40 begitu salah satu sisi paket dalam adalah IPv6, karena header bersarang tumbuh dari 20 byte menjadi 40. Tidak ada hal lain yang termasuk dalam pengurangan itu. Overhead WireGuard sudah terpakai saat Anda memilih 1420, dan menagihnya dua kali menghasilkan tunnel yang bekerja sempurna dan tetap lambat selama tidak ada yang mengukurnya. Penerapan di mana kedua perangkat membawa 1400 bulat adalah sidik jari kesalahan itu.

IPv6 di salah satu sisi paket bersarang membatalkan setiap angka di atas, jadi hitung ulang alih-alih menyalin angka dari situs serupa. Header yang dikurangi masing-masing 40 byte begitu IPv6 muncul di jalur luar atau di datagram asli, dan angka payload turun tepat sebanyak itu.

Aturan firewall yang mungkin tidak Anda butuhkan

Antara dua peer WireGuard satu-satunya hal di kabel adalah UDP, jadi aturan masuk untuk protokol 4, nomor yang diberikan RFC 2003 untuk enkapsulasi IPv4-dalam-IPv4, tidak menciptakan jalur bersarang maupun menjaganya tetap hidup. Header IPIP hidup di dalam payload terenkripsi, tempat tidak ada firewall tepi yang melihatnya. Membuka protokol 4 tetap tidak membeli apa pun selain satu lagi jalan yang diizinkan ke host.

Kebijakan yang menyebut sumber dan tujuan paket asli berada setelah dekapsulasi, pada antarmuka tunnel dan di tabel perutean. Letakkan di sana dan aturan tepi dapat tetap tertutup.

Apa yang benar-benar divalidasi WireGuard

AllowedIPs menilai sumber paket yang dibawa WireGuard, dan yang dibawanya adalah paket yang dienkapsulasi IPIP. Sumber IPIP yang diizinkan diterima bahkan ketika header di dalamnya menyebut host yang lebih baik tidak Anda rutekan. Jadi sumber asli bukanlah yang diperiksa peer untuk Anda, dan pasangan alamat dalam itu memerlukan penegakannya sendiri setelah dekapsulasi.

Pembungkus menyediakan struktur perutean, bukan lapisan kriptografi kedua. Menyebut IPIP perlindungan tambahan di dalam WireGuard menggambarkan desain yang berbeda.

Verifikasi dengan tangga, bukan satu ping

Uji ukuran yang mengapit batas yang Anda hitung, lalu pastikan apa yang diyakini kernel tentang kedua perangkat. Dengan 1360 byte payload plus 40 byte header menjadi 1400, gema pertama di bawah muat dan yang kedua duduk satu byte melewati plafon:

ping -M do -s 1372 10.9.0.2
ping -M do -s 1373 10.9.0.2
wg show wg0
ip -d link show ipip0

Lolos bersih di bawah plafon dan gagal pada ukuran pertama di atasnya berarti aritmetika bertahan dari ujung ke ujung. Lalu jalankan ulang transfer yang semula tersendat, karena probe sintetis membuktikan anggaran dan tidak mengatakan apa pun tentang ukuran tulis pengirim sendiri. Jika jalur bersarang masih putus pada ukuran yang Anda buktikan muat, periksa dekapsulasi dan rute ujung jauh sebelum memotong sepuluh byte lagi dari MTU.