IPIP di dalam WireGuard: 20 bait tambahan yang tiada siapa anggarkan

Ping kecil merentasi terowong sepanjang hari, sepanduk SSH tiba, dan kemudian sesi membeku pada saat pemindahan fail bermula. Corak itu menunjuk kepada belanjawan bait yang dikira pada lapisan salah, di mana terowong luar diukur untuk overhednya sendiri dan tiada siapa menolak yang dalam. Paket IPIP bersarang hanyalah satu lagi paket IP bagi WireGuard, dan sebab itulah ia menggunakan bait yang tidak pernah anda rezervasikan. Pembetulannya ialah aritmetik, dan ia muat dalam tiga arahan dan satu jadual.

Gejala yang mendedahkannya

Masalah pemecahan mengumumkan dirinya melalui saiz, tidak pernah melalui alamat. Rakan anda menjawab ping 56 bait selama satu jam dan kemudian mendiamkan diri pada 1400 bait sementara terowong kekal naik dan tiada laluan berubah. Jabat tangan muat, tetingkap TCP penuh pertama tidak, dan pemindahan terhenti beberapa saat selepas ia kelihatan sihat.

Ukur siling sebelum anda mengedit apa-apa, kerana siling yang tidak diukur ialah yang akan anda kejar dua kali. Hantar satu prob di bawah saiz yang disyaki dengan bit do-not-fragment ditetapkan, ping -M do -s 1000 10.9.0.2, kemudian ulangi pada saiz yang anda sudah tahu terlalu besar. Apabila pembalikan mengikut saiz muatan sementara destinasi kekal tidak berubah, penghalaan menjalankan tugasnya dan satu pengepala hilang daripada belanjawan.

Kira setiap pengepala sekali, pada lapisan yang betul

Mulakan dari MTU terkecil pada laluan dan bukan dari antara muka terowong, kerana dinding berada di hulu kedua-dua hujung. WireGuard membelanjakan 60 bait pada pengangkutan luar IPv4: 20 untuk IP, 8 untuk UDP dan 32 untuk pengepalanya sendiri, dan 80 bait apabila pengangkutan itu IPv6. wg0 1420 bait menyimpan 20 bait kelonggaran di bawah 1440 yang benar-benar boleh disampaikan oleh laluan 1500 bait, dan sebab itulah angka yang disalin dari wiki masih sesuai di sini. Lukis seluruh tindanan pada rajah, kerana sesiapa yang menukar MTU seterusnya jika tidak akan memilih nombor bulat baharu dan mewarisi pepijat anda.

Baris kelima ialah tempat belanjawan menjadi kacau, kerana 1400 bait yang dibawa antara muka bersarang sudah termasuk 40 bait pengepala paket asal itu sendiri. Hanya 1360 daripada bait itu sampai ke proses yang membaca fail. Anggap 1400 sebagai muatan aplikasi, seperti yang dijemput oleh mana-mana rajah tanpa lajur itu, dan peranti dalaman berakhir 40 bait terlalu pemurah terhadap dinding yang tidak bergerak.

Tetapkan kedua-dua MTU secara berasingan

Pembawa dan peranti bersarang ialah objek berasingan, jadi setiap satu memerlukan nilainya sendiri. Gunakannya dalam urutan ini, kerana peranti bersarang tidak mewarisi apa-apa daripada 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

Peraturan yang wajar dihafal: MTU dalam = MTU luar - 20 apabila paket yang dibawa terowong IPIP ialah IPv4, dan - 40 sebaik sahaja mana-mana sisi paket dalam ialah IPv6, kerana pengepala bersarang membesar dari 20 bait kepada 40. Tiada apa-apa lagi yang termasuk dalam penolakan itu. Overhed WireGuard sudah dibelanjakan apabila anda memilih 1420, dan mengenakannya dua kali menghasilkan terowong yang berfungsi dengan sempurna dan kekal perlahan selagi tiada siapa mengukurnya. Penggunaan di mana kedua-dua peranti membawa 1400 bulat ialah cap jari kesilapan itu.

IPv6 pada mana-mana sisi paket bersarang membatalkan setiap angka di atas, jadi kira semula dan bukannya menyalin nombor dari laman yang serupa. Pengepala yang ditolak ialah 40 bait setiap satu sebaik sahaja IPv6 muncul dalam laluan luar atau dalam datagram asal, dan angka muatan menurun tepat sebanyak itu.

Peraturan tembok api yang anda mungkin tidak perlukan

Antara dua rakan WireGuard satu-satunya perkara pada wayar ialah UDP, jadi peraturan masuk untuk protokol 4, nombor yang diberikan RFC 2003 kepada enkapsulasi IPv4-dalam-IPv4, tidak mencipta laluan bersarang dan tidak mengekalkannya hidup. Pengepala IPIP hidup di dalam muatan yang disulitkan, di mana tiada tembok api tepi melihatnya. Membuka protokol 4 tetap tidak membeli apa-apa selain satu lagi jalan yang dibenarkan ke hos.

Dasar yang menyebut sumber dan destinasi paket asal terletak selepas dekapulasi, pada antara muka terowong dan dalam jadual penghalaan. Letakkan di sana dan peraturan tepi boleh kekal tertutup.

Apa yang sebenarnya disahkan WireGuard

AllowedIPs menilai sumber paket yang dibawa WireGuard, dan apa yang dibawanya ialah paket yang dienkapsulasi IPIP. Sumber IPIP yang dibenarkan diterima walaupun pengepala di dalamnya menamakan hos yang anda lebih suka tidak halakan. Jadi sumber asal bukanlah apa yang rakan anda semak untuk anda, dan pasangan alamat dalam itu memerlukan penguatkuasaannya sendiri selepas dekapulasi.

Pembalut menyediakan struktur penghalaan, bukan lapisan kriptografi kedua. Memanggil IPIP perlindungan tambahan di dalam WireGuard menggambarkan reka bentuk yang berbeza.

Sahkan dengan tangga, bukan satu ping

Uji saiz yang merentasi sempadan yang anda kira, kemudian sahkan apa yang dipercayai kernel tentang kedua-dua peranti. Dengan 1360 bait muatan ditambah 40 bait pengepala menjadikan 1400, gema pertama di bawah muat dan yang kedua duduk satu bait melepasi siling:

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

Lulus bersih di bawah siling dan kegagalan pada saiz pertama di atasnya bermakna aritmetik itu bertahan dari hujung ke hujung. Kemudian jalankan semula pemindahan yang asalnya tersekat, kerana prob sintetik membuktikan belanjawan dan tidak berkata apa-apa tentang saiz tulisan pengirim sendiri. Jika laluan bersarang masih pecah pada saiz yang anda buktikan muat, periksa dekapulasi dan laluan hujung jauh sebelum memotong sepuluh bait lagi daripada MTU.