WireGuard İçinde IPIP: Kimsenin Bütçelemediği O 20 Bayt

Küçük ping'ler gün boyu tünelden geçer, SSH başlığı gelir ve ardından bir dosya aktarımı başladığı anda oturum donar. Bu örüntü, dış tünelin kendi ek yüküne göre boyutlandırıldığı ve kimsenin içteki tüneli düşmediği yanlış katmanda sayılmış bir bayt bütçesine işaret eder. İç içe bir IPIP paketi WireGuard için yalnızca bir başka IP paketidir ve tam da bu yüzden hiç ayırmadığınız baytları tüketir. Düzeltme aritmetiktir ve üç komut ile bir tabloya sığar.

Ele veren belirti

Parçalanma sorunu kendini boyutla bildirir, asla adreslerle değil. Eşiniz bir saat boyunca 56 baytlık ping'a yanıt verir, sonra tünel ayakta kalırken ve hiçbir rota değişmezken 1400 baytta susar. El sıkışma sığar, ilk tam TCP penceresi sığmaz ve aktarım sağlıklı göründükten saniyeler sonra durur.

Herhangi bir şeyi düzenlemeden önce tavanı ölçün, çünkü ölçülmemiş tavan iki kez peşinden gideceğiniz tavandır. Şüpheli boyutun altında do-not-fragment biti ayarlanmış bir sonda gönderin, ping -M do -s 1000 10.9.0.2, ardından çok büyük olduğunu bildiğiniz bir boyutta tekrarlayın. Hedef değişmezken dönüş yük boyutunu izliyorsa, yönlendirme işini yapıyordur ve bütçeden bir başlık eksiktir.

Her başlığı bir kez sayın, doğru katmanda

Tünel arayüzünden değil, yol üzerindeki en küçük MTU'dan başlayın, çünkü duvar iki uç noktanın da yukarısındadır. WireGuard bir IPv4 dış taşıma için 60 bayt harcar: 20'si IP, 8'i UDP ve 32'si kendi başlığı için, o taşıma IPv6 olduğunda 80 bayt. 1420 baytlık bir wg0, 1500 baytlık bir yolun gerçekten teslim edebileceği 1440'ın altında 20 bayt boşluk bırakır ve bu yüzden bir wiki'den kopyalanan sayı hâlâ buraya uyar. Bütün yığını şemaya çizin, çünkü MTU'yu bir sonraki değiştiren kişi aksi hâlde yeni ve yuvarlak bir sayı seçer ve sizin hatanızı devralır.

Beşinci satır bütçelerin bozulduğu yerdir, çünkü iç içe arayüzün taşıdığı 1400 bayt, özgün paketin kendi 40 bayt başlığını zaten içerir. Bu baytların yalnızca 1360'ı dosyayı okuyan sürece ulaşır. 1400'ü uygulama yükü sayın, o sütunu olmayan her şemanın sizi davet ettiği gibi, ve içteki aygıt yerinden kıpırdamayan bir duvarın önünde 40 bayt fazla cömert kalır.

İki MTU'yu ayrı ayrı ayarlayın

Taşıyıcı ve iç içe aygıt ayrı nesnelerdir, bu yüzden her biri kendi değerine ihtiyaç duyar. Onları bu sırayla uygulayın, çünkü iç içe aygıt taşıyıcıdan hiçbir şey devralmaz:

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

Hatırlamaya değer kural: iç MTU = dış MTU - 20, IPIP tünelinin taşıdığı paket IPv4 olduğunda ve iç paketin herhangi bir tarafı IPv6 olduğu anda - 40, çünkü iç içe başlık 20 bayttan 40'a çıkar. Bu çıkarmaya başka hiçbir şey girmez. WireGuard'ın ek yükü 1420'yi seçtiğinizde zaten harcanmıştı ve onu iki kez tahsil etmek kusursuz çalışan ve kimse ölçmediği sürece yavaş kalan bir tünel üretir. İki aygıtın da yuvarlak 1400 taşıdığı bir kurulum, tam olarak o hatanın parmak izidir.

İç içe paketin herhangi bir tarafındaki IPv6 yukarıdaki her sayıyı geçersiz kılar, bu yüzden benzer bir siteden sayı kopyalamak yerine yeniden hesaplayın. Çıkarılan başlıklar, IPv6 dış yolda veya özgün veri biriminde göründüğü anda 40'ar bayttır ve yük sayısı tam o kadar düşer.

Muhtemelen ihtiyacınız olmayan güvenlik duvarı kuralı

İki WireGuard eşi arasında kablodaki tek şey UDP'dir, bu yüzden protokol 4 için, RFC 2003'ün IPv4-içinde-IPv4 kapsüllemesine verdiği numara için bir giriş kuralı ne iç içe yolu oluşturur ne de onu canlı tutar. IPIP başlığı şifrelenmiş yükün içinde yaşar, orada hiçbir kenar güvenlik duvarı onu görmez. Protokol 4'ü yine de açmak, ana bilgisayara bir izinli yol daha kazandırmaktan başka bir şey satın almaz.

Özgün paketin kaynaklarını ve hedeflerini anan ilke, kapsülden çıkarma sonrasında, tünel arayüzlerinde ve yönlendirme tablosunda yer alır. Onu oraya koyun ve kenar kuralı kapalı kalabilir.

WireGuard'ın gerçekte neyi doğruladığı

AllowedIPs WireGuard'ın taşıdığı paketin kaynağını yargılar ve taşıdığı şey IPIP ile kapsüllenmiş pakettir. İzin verilen bir IPIP kaynağı, içteki başlık yönlendirmek istemeyeceğiniz bir ana bilgisayarı adlandırsa bile kabul edilir. Dolayısıyla özgün kaynak, eşin sizin için denetlediği şey değildir ve o iç adres çifti kapsülden çıkarma sonrasında kendi yaptırımına ihtiyaç duyar.

Sarmalayıcı yönlendirme yapısı sağlar, ikinci bir şifreleme katmanı değil. IPIP'i WireGuard içinde ekstra koruma olarak adlandırmak farklı bir tasarımı tarif eder.

Tek bir ping ile değil, bir merdivenle doğrulayın

Hesapladığınız sınırı iki yandan kuşatan boyutları deneyin ve ardından çekirdeğin iki aygıt hakkında ne düşündüğünü doğrulayın. 1360 bayt yük artı 40 bayt başlık 1400 yaptığında, aşağıdaki ilk yankı sığar ve ikincisi tavanın bir bayt ötesinde oturur:

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

Tavanın altında temiz geçiş ve üstündeki ilk boyutta başarısızlık, aritmetiğin uçtan uca tuttuğu anlamına gelir. Ardından başlangıçta takılan aktarımı yeniden çalıştırın, çünkü sentetik sonda bütçeyi kanıtlar ve gönderenin kendi yazma boyutları hakkında hiçbir şey söylemez. İç içe yol, sığdığını kanıtladığınız bir boyutta hâlâ kırılıyorsa, MTU'dan on bayt daha kırpmadan önce uzak uçtaki kapsülden çıkarmayı ve rotaları inceleyin.