WireGuard hız düşüklüğü nasıl giderilir?

WireGuard hız düşüklüğünün gerçek kaynakları

WireGuard hız düşüklüğü dört temel nedenden kaynaklanır ve bu nedenlerin gerçekleşme olasılıkları eşit değildir. Birincisi MTU (maximum transmission unit) değeridir: tünel, yol üzerindeki bir bağlantı için çok büyük paketler oluşturur; bu nedenle küçük veri aktarımları sorunsuz görünürken toplu aktarımlar duraksar. İkincisi, tünel kurulmadan önce de mevcut olan bağlantı yolunun kendi kısıtlamalarıdır. Üçüncüsü, küçük ve paylaşımlı bir VPS üzerindeki CPU kullanımıdır; burada şifreleme işlemi, aynı ana makine üzerindeki diğer tüm konuklarla kaynak rekabetine girer. Dördüncüsü ise eşin (peer) kendi bağlantı kalitesidir.

Bu maddeleri belirtilen sırayla kontrol edin. MTU ilk sırada yer alır çünkü listede WireGuard'ın kendisinden kaynaklanan tek sorun budur ve belirtileri doğrudan yavaşlık gibi görünmez. Yanlış bir MTU değeri genellikle tünelin anında bağlanması, ping komutuna yanıt vermesi ve SSH girişini kabul etmesi, ancak bir dosya kopyalamaya çalıştığınızda donması şeklinde ortaya çıkar.

Diğer adımlara geçmeden önce bir belirtiyi elemekte fayda vardır. Eğer her yeni site yüklenmeye başlamadan önce birkaç saniye bekletiyor ve ardından tam hızda veri aktarıyorsa, sorun bant genişliği değil isim çözümlemedir. DNS over WireGuard yapısının kendine özgü hata modları vardır ve hiçbir MTU değişikliği bu sorunu çözmez.

WireGuard MTU değeri neden 1420'dir?

Tünele gönderdiğiniz her paket şifrelenir ve yeni bir paketin içine sarılır. Bu sarmalama işlemi bayt maliyeti getirir ve bu baytlar veri yükünüzden (payload) düşülür.

WireGuard veri başlığı 32 bayttır: 4 baytlık tip alanı, 4 baytlık alıcı indeksi, 8 baytlık sayaç ve 16 baytlık Poly1305 kimlik doğrulama etiketi. Bunun etrafında 8 baytlık bir UDP başlığı bulunur. Onun da etrafında, IPv4 için 20 bayt, IPv6 için 40 bayt olan dış IP başlığı yer alır. Dolayısıyla, Endpoint bir IPv4 adresi olduğunda toplam kapsülleme 60 bayt, IPv6 olduğunda ise 80 bayttır. WireGuard protokol sayfası, bu sayıların türetildiği mesaj düzenini belgeler.

wg-quick bu konuda tahminde bulunmaz. Endpoint adresinize giden arayüzün MTU değerini okur ve bundan 80 çıkarır. Standart 1500 baytlık bir Ethernet yolunda bu işlem 1420 sonucunu verir; ip link show wg0 tarafından yazdırılan değer de budur. 60 yerine 80 çıkarılmasının nedeni, uç noktanın dış başlığın 20 bayt daha büyük olduğu IPv6 üzerinden erişilmesi durumunda bile aynı değerin güvenli kalmasını sağlamaktır.

[
  {
    "label": "Ethernet, IPv4 endpoint",
    "path_mtu": 1500,
    "encap_overhead": 60,
    "usable_wg0_mtu": 1440
  },
  {
    "label": "Ethernet, IPv6 endpoint",
    "path_mtu": 1500,
    "encap_overhead": 80,
    "usable_wg0_mtu": 1420
  },
  {
    "label": "PPPoE DSL, IPv4 endpoint",
    "path_mtu": 1492,
    "encap_overhead": 60,
    "usable_wg0_mtu": 1432
  },
  {
    "label": "Extra tunnel in the path",
    "path_mtu": 1400,
    "encap_overhead": 80,
    "usable_wg0_mtu": 1320
  }
]

4 satırlık tablo ölçümlere değil, aritmetik hesaplamalara dayanır. IPv4 uç noktasına sahip temiz bir 1500 baytlık yolda 1440 değeri sığacaktır, bu nedenle 1420 varsayılan değeri 20 baytı boş bırakır. Bu pay kasıtlıdır ve bir sorun teşkil etmez.

Son satır kritik olandır. Yol üzerindeki bir bağlantı yalnızca 1400 bayt taşıyabiliyorsa, 1420 değerine ayarlanmış bir tünel, tam boyutlu her segmentte 1500 baytlık bir dış paket üretir; bu da bağlantının kabul edebileceğinden 100 bayt fazladır. Sığacak olan değer 1320 değeridir.

1320 değerini de doğrudan kopyalamayın. Yol MTU değeriniz, yolunuzun bir özelliğidir ve bunu öğrenmenin tek yolu ölçüm yapmaktır.

Yanlış MTU yapılandırmasının belirtileri

Hata kademeli gerçekleşmez. Küçük paketler ile büyük paketler arasında net bir ayrım oluşur.

• Tünel üzerinden ping, normal boyutlardaki her türlü veri ile çalışır.
• SSH girişi tamamlanır ve yazma işlemleri hızlı yanıt verir.
• curl -I https://example.com, başlıkları anında döndürür.
• Büyük bir sayfada curl https://example.com, ilk birkaç kilobayttan sonra takılır.
• Büyük bir dosyanın scp işlemi başlar ve belirli bir yüzdeye ulaştığında durur.
• Çok miktarda çıktı üreten bir komut çalıştırdığınız anda SSH oturumu donar.

Tüm bunlar, bir TCP bağlantısının ancak taşınacak toplu veri olduğunda tam boyutlu segmentler oluşturması nedeniyle yaşanır. El sıkışma (handshake) ve ilk istek, yol üzerindeki her MTU değerine sığar. Duraksama, ilk tam boyutlu segmentte başlar; bu nedenle bağlantı, kullanılamaz hale geldiği ana kadar sağlıklı görünür.

Bir sonraki bağlantının MTU değerinden daha büyük olan bir dış paket, iki sonuçtan biriyle karşılaşır.

Paket parçalanır (fragmented). Bir yönlendirici paketi böler ve karşı uç parçaları yeniden birleştirir. Aktarım çalışır ancak yavaşlar; çünkü artık tek bir paket yerine iki paketle işlem yaparsınız ve alıcı taraf, her iki parça da ulaşana kadar durumu bellekte tutar. Parçalardan birinin kaybolması orijinal paketin tamamının kaybolması anlamına gelir; bu yüzden %1 kayıp oranına sahip bir yol, çok daha kötü bir yol gibi davranır. Birçok güvenlik duvarı, politika gereği IP parçalarını reddeder; bu durum, sonucu bir sonraki maddeye dönüştürür.

Paket düşürülür ve size bilgi verilmeyebilir. Parçalama yapmayan bir yönlendirici, göndericiye kabul edebileceği MTU değerini içeren bir ICMP (internet control message protocol) "fragmentation needed" mesajı gönderir. Eğer bu mesaj ulaşırsa, path MTU discovery çalışır ve gönderici segment boyutunu kendiliğinden düşürür. Birçok ağ ICMP trafiğini filtrelediği için bu mesaj genellikle ulaşmaz. Başka hiçbir mekanizma kaybı rapor etmez. İşte "kara delik" budur: paket çıkar, geri dönüş olmaz, her iki uçtaki hiçbir günlükte hata görünmez ve aktarım, bir zaman aşımı gerçekleşene kadar askıda kalır.

Doğru MTU değerini nasıl bulurum?

Yolu ölçün ve ardından çıkarma işlemini yapın. Tünel yerine alt katmanı (underlay) test edin; bu nedenle istemciden sunucunun genel IP adresine ping atın ve paket parçalanmasını (fragmentation) yasaklayın.

ping -M do -s 1472 -c 3 203.0.113.10

-M do, DF (parçalama) bitini ayarlar, böylece yoldaki hiçbir yönlendiricinin paketi bölmesine izin verilmez. -s, ICMP yük boyutudur. Tam bir IPv4 paketi, bu yük ile 8 baytlık ICMP başlığı ve 20 baytlık IP başlığının toplamıdır; bu nedenle -s 1472, hatta tam olarak 1500 bayt gönderir.

Üç sonuç önemlidir. Temiz yanıtlar, 1500 baytın sığdığını ve MTU'nun sorununuz olmadığını gösterir. Yerel bir hata, kendi arayüzünüzün zaten talep ettiğinizden daha küçük olduğunu belirtir:

ping: local error: message too long, mtu=1500

Yoldaki bir yönlendiriciden gelen yanıt size cevabı doğrudan verir ve burada durabilirsiniz:

From 203.0.113.1 icmp_seq=1 Frag needed and DF set (mtu = 1492)

1472 baytta %100 paket kaybı ve daha küçük boyutlarda temiz yanıtlar alıyorsanız, bu bir "kara delik" durumudur. Hiçbir yönlendirici size bilgi vermediği için, ikiye bölme yöntemiyle sınırı bulun. Çalıştığını bildiğiniz bir boyut ile başarısız olduğunu bildiğiniz bir boyutu tutun, orta noktayı test edin ve sonucu hangi sınıra aitse o yöne doğru ilerleyin. Her tur kalan aralığı yarıya indirir, bu nedenle beş veya altı tur yeterlidir.

ping -M do -s 1472 -c 3 203.0.113.10   # 100% loss, so 1500 is too big
ping -M do -s 1272 -c 3 203.0.113.10   # replies, so 1300 fits
ping -M do -s 1372 -c 3 203.0.113.10   # replies, so 1400 fits
ping -M do -s 1422 -c 3 203.0.113.10   # 100% loss, so 1450 is too big
ping -M do -s 1397 -c 3 203.0.113.10   # 100% loss, so 1425 is too big
ping -M do -s 1384 -c 3 203.0.113.10   # 100% loss, so 1412 is too big

tracepath, aynı aramayı kendi başına çalıştırır ve manuel bölme işlemine başlamadan önce bir kez çalıştırmaya değerdir:

tracepath -n 203.0.113.10

Son satırı bulduğu sonucu raporlar:

     Resume: pmtu 1492 hops 12 back 12

Her iki aracı da kanıt olarak değil, bir başlangıç noktası olarak değerlendirin. Bazı ana bilgisayarlar ICMP trafiğini hız sınırlar veya tamamen engeller, bu nedenle ikiye bölme yöntemi yolun gerçekte taşıdığından daha küçük bir MTU rapor edebilir. Başarısız olan aktarım, gerçek testtir.

Değeri önce canlı olarak uygulayın, çünkü yanlış bir tahmin durumunda tek bir komutla geri alabilirsiniz:

sudo ip link set mtu 1320 dev wg0

Takılan aktarımı yeniden deneyin. Eğer tamamlanırsa, değeri istemcinin [Interface] bloğunda kalıcı hale getirin:

[Interface]
PrivateKey = <client private key>
Address = 10.8.0.2/32
MTU = 1320

sudo wg-quick down wg0 && sudo wg-quick up wg0
ip link show wg0

ip link show wg0 artık mtu 1320 çıktısını vermelidir. Eğer hala eski değeri veriyorsa, wg-quick düzenlediğiniz dosyayı okumamıştır. /etc/wireguard/wg0.conf dosyasını düzenlediğinizden ve MTU ifadesinin [Interface] altında olduğundan, yok sayıldığı [Peer] altında olmadığından emin olun.

MTU, bir arayüzün özelliğidir ve eşler arasında asla müzakere edilmez. Bunu yalnızca istemcide ayarlamak, istemcinin gönderdiği paketleri küçültür. Sunucu, kendi wg0 MTU değerinde paketler oluşturmaya devam eder, bu nedenle yüklemeler çalışmaya başlasa bile indirmeler hala kara deliğe düşebilir. Değeri her iki uçta da ayarlayın veya sunucuda MSS değerini sınırlayın (clamp).

MSS clamping neden yalnızca TCP sorunlarını çözer

Sunucu, NAT (network address translation) kullanan herhangi bir standart WireGuard VPS kurulumunda olduğu gibi, eşleri için trafik yönlendiriyorsa, tek bir kural tüm eşler için TCP sorununu çözer ve kontrolünüz dışındaki her bir istemci üzerinde değer arama zahmetinden sizi kurtarır.

MSS (maximum segment size), her iki tarafın da almaya istekli olduğu segment boyutunu belirtmek için SYN paketine eklediği bir TCP seçeneğidir. Clamping işlemi, bu seçeneği gerçek rota MTU değerine uyacak şekilde paket iletimi sırasında yeniden yazar; böylece her iki uç da veri aktarımı başlamadan önce daha küçük bir segment boyutu üzerinde anlaşır. Bu yöntem, el sıkışma sırasında gerçekleştiği ve yol üzerindeki cihazların muhtemelen filtrelediği ICMP mesajlarına bağımlı olmadığı için çalışır.

nftables ile, mevcut tablolarınızın altına /etc/nftables.conf kısmına şu tabloyu ekleyin:

table inet mangle {
  chain forward {
    type filter hook forward priority mangle; policy accept;
    tcp flags syn tcp option maxseg size set rt mtu
  }
}

sudo systemctl reload nftables ile yeniden yükleyin. iptables kullanan bir sistemde eşdeğeri tek bir satırdır:

sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Kuralın paketlerin izlediği yol üzerinde olduğunu doğrulayın. Bir istemci yeni bağlantılar açarken sudo nft list table inet mangle veya sudo iptables -t mangle -L FORWARD -n -v komutunu çalıştırın ve sayacın arttığını gözlemleyin. Sıfırda takılı kalan bir sayaç, paketlerin ilgili kancadan (hook) geçmediği ve kuralın hiçbir işlev görmediği anlamına gelir.

Şimdi dürüst sınırlamalara gelelim. Clamping yalnızca TCP'yi kapsar ve başka hiçbir şeyi etkilemez; ayrıca yalnızca yönlendirilen trafiği kapsar. Bu nedenle, doğrudan WireGuard sunucusunun üzerinde çalışan bir servis asla forward kancasından geçmez ve dolayısıyla asla clamping işlemine tabi tutulmaz. Ayrıca bu kural, yalnızca kural yüklendikten sonra açılan bağlantıları etkiler; mevcut oturumlar daha önce anlaştıkları MSS değerini korumaya devam eder.

UDP bu durumdan etkilenmez, çünkü UDP'nin yeniden yazılabilecek bir el sıkışma süreci yoktur. Çoğu UDP trafiği zaten hayatta kalır. HTTP/3'ün temelindeki taşıma protokolü olan QUIC, kendi kullanılabilir paket boyutunu test eder ve başlangıçta küçük boyutlarla çalışır. Hayatta kalamayan tek şey, tek bir büyük datagram gönderip bunun iletilmesini bekleyen UDP trafiğidir; örneğin 1400 bayttan büyük bir DNSSEC (DNS security extensions) yanıtı gibi. Bu tür sorgular zaman aşımına uğrar ve TCP üzerinden tekrar denenir; bu da kullanıcıya sitenin bozuk değil, yavaş çalışması olarak yansır.

VPS işlemcim bir darboğaz mı?

WireGuard, şifreleme için ChaCha20-Poly1305, anahtar değişimi için ise Curve25519 kullanır. Veri yolunun hiçbir noktasında AES bulunmaz; bu durum, insanların yanlış bildiği bir sonucu doğurur: işlemcinizdeki AES-NI komut setleri WireGuard için hiçbir işe yaramaz. AES-NI desteği sunan bir ana makine, size WireGuard performansı açısından bir avantaj sağlamaz. ChaCha20, kriptografik hızlandırması olmayan işlemcilerde dahi yazılımsal olarak hızlı çalıştığı için tercih edilmiştir.

Bu, WireGuard'ın işlemciyi yormadığı anlamına gelmez. 1 vCPU'lu bir VPS üzerinde tek bir çekirdek; uygulamanızın yaptığı işlerin yanı sıra hem şifreleme işlemlerini hem de ağ kesmelerini (interrupts) yönetir.

Bir veri transferi sırasında ölçüm yapın:

sudo apt install -y sysstat
mpstat -P ALL 1

Üç sütunu inceleyin. %soft, çekirdek seviyesindeki paket işleme süreçlerinin gerçekleştiği softirq süresini gösterir. %steal, hipervizörün işlemci süresini başka bir işleme ayırdığı süredir. %idle ise boşta kalan süredir.

Tek çekirdeğinizde %soft değerinin 100'e yaklaşması, sunucunun paket işleme kapasitesinin sınırına ulaştığı anlamına gelir; bu gerçek bir sınırdır ve daha fazla çekirdek ile aşılabilir. Aynı anda top komutunu çalıştırdığınızda listenin en üstünde ksoftirqd/0 sürecini görmeniz, aynı bulguyu farklı bir açıdan doğrular.

%steal değerinin yüzde birkaç seviyesinin üzerine çıkması, sorunun sizin tarafınızdan çözülemeyeceğini gösterir; çünkü ana makine aşırı yüklenmiştir ve vCPU'nuz fiziksel bir çekirdek için sıra bekliyordur. Bu durum, en ucuz paylaşımlı planlarda yaygındır ve gün içinde değişkenlik gösterir. Gürültülü komşudan kaynaklanan steal time sorunu ayrı bir inceleme gerektirir ve hiçbir MTU değeri bu sorunu çözmeye yardımcı olmaz.

Bir diğer faktör ise istemcinin hangi uygulamayı çalıştırdığıdır. Linux kernel modülü en hızlı yoldur ve bir eşin (peer) şifreleme yükünü çekirdekler arasında dağıtabilir. macOS ve iOS istemcilerinin kullandığı kullanıcı alanı (userspace) uygulaması olan wireguard-go ise daha yavaştır; çünkü bu platformlar bir uygulamanın kernel modülü yüklemesine izin vermez.

Sorun yoldan mı kaynaklanıyor, yoksa eşin kendi bağlantısından mı?

Herhangi bir ayar yapmadan önce, aynı istemciden birkaç dakika arayla iki değer alın: tünelsiz veri aktarım hızı ve tünelli veri aktarım hızı. Bu ikili olmadan sadece tahmin yürütmüş olursunuz.

Sunucuda iperf3 -s çalıştırın. Doğrudan test için TCP 5201 portunun genel IP adresinde erişilebilir olması gerekir; bu nedenle testi yaparken portu açın ve işlem bittikten sonra kuralı kaldırın. Portun kapalı olduğunu varsaymak yerine portun tekrar kapandığını doğrulayın.

# on the client, outside the tunnel
iperf3 -c 203.0.113.10
# then through the tunnel
iperf3 -c 10.8.0.1

Eğer iki değer birbirine yakınsa, WireGuard size çok az maliyet çıkarıyordur ve darboğaz hattın kendisidir. Eğer tünel hızı, %soft düşük kalmasına rağmen doğrudan test hızının çok altındaysa, MTU ayarlarına geri dönün. Paket parçalanması (fragmentation), bağlantıyı koparmadan veri aktarım hızını düşürür; bu durum bir takılma olarak değil, yüzde bazında bir kayıp olarak görünür.

Ev interneti bağlantıları genellikle asimetrik olduğu için her iki yönü de test edin. iperf3 -c 10.8.0.1 -R akışı tersine çevirerek sunucunun veri göndermesini sağlar. 500/20 Mbps hızındaki bir hatta sahip istemci, tünel içine 20 Mbps yükleme hızından fazlasını gönderemez ve sunucu tarafındaki hiçbir değişiklik bunu değiştiremez.

Ardından paralel akışlarla test yapın:

iperf3 -c 10.8.0.1 -P 4

Eğer dört akış birlikte tek bir akıştan çok daha fazla veri taşıyorsa, tek bir TCP bağlantısı hattı tam kapasiteyle dolduramıyordur. Tek bir akışın hızı, alıcı penceresinin (receive window) gidiş-dönüş süresine (RTT) bölünmesiyle sınırlanır; bu nedenle 150 ms gecikmeli bir hattın yüksek veri taşıyabilmesi için büyük bir pencereye ihtiyacı vardır. Kendi sınırlarınızı okuyun:

sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem

Her satırdaki üçüncü değer, Linux'un otomatik olarak ayarlayabileceği maksimum değerdir. Paket kaybı da tek bir akışı ciddi şekilde sınırlar, çünkü TCP tıkanıklık denetimi (congestion control) paket kaybına tepki verir ve uzun bir yolda kayıpları telafi etmek maliyetlidir. Kaybın rota boyunca nerede ortaya çıktığını görmek için istemciden mtr -rwc 100 203.0.113.10 komutunu yüz döngü boyunca çalıştırın. Bir sekmede başlayıp son sekmeye kadar devam eden kayıp gerçektir. Sadece bir orta sekmede görünen ve sonrasında kaybolan kayıp, o yönlendiricinin ICMP paketlerine düşük öncelik verdiğini gösterir ve bir anlam ifade etmez.

Sunucunun kendisi hakkında, ağdan bağımsız ve tekrarlanabilir bir resim elde etmek için belgelenmiş bir yöntemle VPS performans testi yapın. Böylece bir değişiklikten sonra aynı testi tekrar çalıştırabilir ve sonuçları kıyaslayabilirsiniz.

WireGuard'ın çözemediği sorunlar

WireGuard bir tüneldir. Kullandığı yol üzerindeki en yavaş bağlantıdan daha hızlı olamaz ve tünel kullanımı yolu her zaman bir miktar yavaşlatır.

Sıkıştırma yapmaz. OpenVPN'in comp-lzo özelliğinin bir karşılığı yoktur ve böyle bir plan da bulunmamaktadır; çünkü şifrelemeden önce sıkıştırma yapmak, düz metin hakkında bilgi sızdırılmasına neden olur. Çoğu toplu veri zaten sıkıştırılmış durumdadır, bu nedenle pratikte bir kayıp yaşanmaz. WireGuard ve OpenVPN karşılaştırması yaparken göz önünde bulundurulması gereken gerçek farklardan biridir ve bilinçli bir tasarım tercihidir.

Tam tünel (full tunnel), her paketin izlediği rotayı değiştirir. Eskiden size yakın bir CDN'e (içerik dağıtım ağı) giden trafik, artık önce VPS'inize, oradan CDN'e gider. Eğer VPS başka bir kıtadaysa, her istek bu dolambaçlı yolu izler ve gidiş-dönüş süresi (RTT) buna göre artar. Hiçbir yapılandırma değeri bu süreyi kısaltamaz. VPS'i daha yakına taşıyın veya yalnızca VPN gerektiren trafiğin uzun yolu izlemesi için split tunnel kullanın. Hangi trafiğin nereye gideceğine tamamen AllowedIPs karar verir ve cryptokey routing bu kararın nasıl verildiğini açıklar.

Sağlayıcı limitleri tünelin dışındadır ve bunları unutmak kolaydır. Aylık bant genişliği kotası olan bir plan, kota dolduğunda portu çok daha düşük bir hıza düşürebilir; bu durumda tünel bozuk görünebilir. MTU ayarlarıyla bir akşamınızı harcamadan önce panelinizi kontrol edin.

PersistentKeepalive verimliliği (throughput) etkilemez. Varlığı, bir ev yönlendiricisinin arkasındaki istemciye sunucunun ulaşabilmesi için NAT eşlemesini açık tutmaktır. Bu değeri 25 saniyenin altına düşürmek sadece ek paket yükü getirir ve hiçbir sorunu çözmez.

Ölçümleri bu sırayla gerçekleştirin

1. Sorunu yeniden oluşturun ve durumun bir donma mı yoksa sadece yavaşlama mı olduğunu not edin. Donma, MTU kaynaklı bir soruna işaret eder. Düzenli bir yavaşlama ise MTU ile ilgili değildir.
2. İstemciden sunucunun genel IP adresine ping -M do ile ikili arama (bisect) yapın ve path MTU değerini not edin.
3. Değerden 80 çıkarın, bu MTU değerini her iki uçta wg0 arayüzüne atayın ve başarısız olan aktarımı tekrar test edin.
4. Sunucu, eşler (peers) için trafik yönlendiriyorsa sunucu üzerinde MSS clamping özelliğini etkinleştirin.
5. Bir aktarım sırasında mpstat -P ALL 1 komutunu çalıştırın ve %soft ile %steal çıktılarını inceleyin.
6. Tünel dışında ve içinde, her iki yönde, tek akışlı ve -P 4 ile iperf3 komutunu çalıştırın.
7. Sunucuya mtr -rwc 100 komutunu çalıştırın ve son sıçramaya (hop) kadar devam eden paket kaybı olup olmadığını kontrol edin.

Sunucu planını yalnızca 5. adımdaki veriler CPU kapasitesinin sınırına ulaşıldığını gösterdiğinde değiştirin. 1'den 4'e kadar olan adımlar ücretsizdir ve yavaş tünel bildirimlerinin çoğunu çözüme kavuşturur.

FAQ

WireGuard tünelim ping için hızlıyken indirme işlemlerinde neden yavaş?

Bu durum, bir MTU sorununun tipik göstergesidir. Küçük paketler yol üzerindeki tüm bağlantılardan geçebilir, bu nedenle ping ve SSH girişi çalışır. Toplu veri aktarımı tam boyutlu segmentler gönderir; bunların kapsüllenmiş hali, yol üzerindeki bazı bağlantıların kabul ettiğinden daha büyüktür. Eğer yönlendirici bu paketleri bir ICMP mesajı döndürmeden düşürürse, kayıp raporlanmaz ve aktarım askıda kalır. Sunucunun genel IP adresine ping -M do ile ikili arama (bisection) yaparak yol MTU değerini bulun, kapsülleme için 80 bayt çıkarın ve elde ettiğiniz sonucu her iki uçta wg0 MTU değeri olarak ayarlayın.

WireGuard için hangi MTU değerini ayarlamalıyım?

Evrensel bir sayı yoktur; varsayılan 1420 değerinin bazı kullanıcılar için başarısız olmasının nedeni tam olarak budur. 1420 değeri, 1500 bayttan WireGuard başlığı, UDP başlığı ve dış IPv6 başlığı için gereken 80 baytın çıkarılmasıyla elde edilir. Eğer yolunuz 1500 bayttan daha azını taşıyorsa (PPPoE DSL bağlantılarında ve trafiğinizin başka bir tünelden geçtiği durumlarda bu normaldir), daha küçük bir değer kullanmanız gerekir. Önce yol MTU değerinizi ölçün, ardından bu değerden 80 çıkarın.

MSS clamping, MTU ayarının yerini tutar mı?

Hayır. Clamping, TCP el sıkışmasındaki MSS seçeneğini yeniden yazar, böylece her iki uç da daha küçük segmentler gönderir; bu işlem arayüze dokunmadan TCP sorununu çözer. UDP'nin yeniden yazılabilecek bir el sıkışması yoktur, bu nedenle etkilenmez. Clamping ayrıca yalnızca sunucunun yönlendirdiği trafiğe uygulanır, bu yüzden doğrudan WireGuard sunucusu üzerinde çalışan bir servis bundan faydalanamaz. Her ikisini de kullanın: arayüz üzerinde doğru bir MTU değeri ve yapılandırmasını kontrol edemediğiniz istemcileri yakalamak için clamping.

Daha hızlı bir VPS planı WireGuard'ı hızlandırır mı?

Yalnızca CPU sınırlayıcı faktörse hızlandırır; bunu tek bir komutla anlayabilirsiniz. Aktarım devam ederken mpstat -P ALL 1 komutunu çalıştırın. Tek çekirdeğinizde %soft değerinin 100'e yakın olması, paket işlemenin darboğaz olduğunu ve daha fazla çekirdeğin bu sınırı yükselteceğini gösterir. Yüksek bir %steal değeri, sunucunun aşırı yüklendiğini gösterir; bu durumda çözüm farklı bir plan veya farklı bir sağlayıcıdır. Tünel yavaşken her iki değer de düşükse, CPU boştadır ve daha üst bir plan hiçbir şeyi değiştirmez.

Aynı ağda olmama rağmen Mac istemcim neden Linux istemcimden daha yavaş?

Linux istemcisi, paketleri çekirdek alanında (kernel space) işleyen ve bir eşin şifreleme yükünü CPU çekirdeklerine dağıtan çekirdek içi WireGuard modülünü kullanır. macOS ve iOS uygulamaları, bu platformlar bir uygulamanın çekirdek modülü yüklemesine izin vermediği için kullanıcı alanı (userspace) uygulaması olan wireguard-go kullanır. Kullanıcı alanı, her paketi çekirdek ile uygulama arasında kopyalar ve bu kopyalama işlemi bant genişliğini düşürür. Bu performans farkı beklenen bir durumdur ve hiçbir istemci ayarı bunu ortadan kaldırmaz.