VPN ping çalışıyor ama site donuyor: boyutu kontrol edin

Yankı yanıtları geliyor, uzak masaüstü çalışıyor ve tarayıcı pes edene kadar boş bir sayfada bekliyor. Bu desene iki açıklama uyuyor ve bunlar tek bir sorunun varyantları değil: hizmete hiç izin vermemiş bir ilke ya da aktarım büyüdükçe sığmamaya başlayan paketler. Yankı yanıtı ikisini de dışlamıyor.

En küçük sorudan en büyüğe doğru ilerleyin ve her adımın gerçekte neyi kanıtladığını yazın.

Yankı yanıtı çok daha küçük bir soruyu yanıtlar

Yankı yanıtı, hedefin IP yığınının sizin kaynağınızdan gelen bir ICMP isteğine yanıt verdiğini söyler. İhtiyacınız olan bağlantı noktasında bir TCP dinleyicisi olup olmadığı, bir ilkenin o bağlantı noktasına izin verip vermediği veya hedef ana bilgisayarın trafiği ağ geçidinden bağımsız olarak süzüp süzmediği hakkında hiçbir şey söylemez. Bir hizmete izin veren ağ geçidi, iki hedef de ping'e yanıt verirken diğerini düşürebilir. Yanıtı tek bir paket ve tek bir yön hakkında tek bir olgu olarak okuyun.

Başka her şeyi yorumlamadan önce hedefi ve hizmet bağlantı noktasını doğrulayın. Test ettiğiniz adres ile uygulamanın kullandığı adres bazen farklı kayıtlardır ve iki adrese çözülen bir ad bunu olası kılar.

Bağlantının başlayıp başlamadığını öğrenin

Hemen reddedilen bir bağlantı dinleyicinin veya ilkenin yanıtıdır: bir şey yanıt verdi ve hayır dedi. Açılıp veri hareket etmeye başlayınca takılan bir bağlantı boyuta işaret eder. El sıkışmayı hiç tamamlamayan bir bağlantı genellikle ilke veya yönlendirme sorunudur ve ret yerine zaman aşımı gibi görünür.

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

MTU ayarlarına dokunmadan önce bu üç durumdan hangisini gözlemlediğinizi yazın. Reddedilen bir bağlantıyı düzeltmek için tünel boyutunu değiştirmek o değişikliği boşa harcar ve gerçek nedeni bir süre gizler.

Boyutu belirtilen sayıyla ölçün

Yük altında takılma göründüğünde, parçalanmayı yasaklayan biti ayarlayarak bir paket boyutu deneyin ve sonucun bir anlam taşıması için aritmetiği belirtin. iputils bulunan Linux'ta 1392 baytlık yük artı 8 baytlık ICMP başlığı ve 20 baytlık IPv4 başlığı tam olarak 1420 baytlık bir iç paket üretir. Bu aritmetiği kayıtta belirtin, çünkü ağ geçidine ulaşan çıplak bir ping bir uygulama hakkında hiçbir şey kanıtlamaz.

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

Her iki sınama da ölçüm noktasıdır, tünel boyutu önerisi değildir. ICMP yolun herhangi bir yerinde süzülüyorsa, zaman aşımı boyut hakkında hiçbir şey söylemez, çünkü süzme ile çok büyük bir paket istemci tarafından aynı görünür. Başarı da ters yön veya başka bir hedef hakkında hiçbir şey söylemez.

Dış yolu hesaba katın

Kapsülleme kendi başlıklarını ekler, bu nedenle kablodaki paket tünel içinde ölçtüğünüz paketten daha büyüktür. İkisi arasındaki fark, çalışan küçük bir istek ile başarısız olan büyük bir isteği aynı anda mümkün kılar.

IPv4'te yol MTU keşfi, parçalanmadan iletilemeyen paketler hakkındaki geri bildirime bağlıdır ve IPv6 Packet Too Big iletilerini kullanır. IPv4 belirtimi bu mekanizmayı açıklar. Geri bildirimi süzmek göndericinin öğrenme yeteneğini bozar ve onu asla sığmayacak paketleri yeniden göndermeye bırakır. Bu yüzden çalışan küçük bir istek ile başarısız olan büyük bir istek bu kadar rahat bir arada yaşar.

Bir sayıyı değiştirin ve uygulamayı yeniden test edin

Tünelin MTU'sunu düşürün veya TCP için en büyük segment boyutunu sınırlayın, sonra sınama yerine özgün uygulama testini yineleyin. Değişiklikten sonra başarılı olan sınama ile hâlâ takılan uygulama benzer biçimli farklı bir sorundur ve yalnızca uygulama testi ikisini ayırt eder.

Aritmetiği değişiklik kaydında tutun: ölçülen boyut, varsaydığınız ek yük ve belirlediğiniz değer. Bunu daha sonra gözden geçiren herkes, varsayımı bir ping ekran görüntüsünden yeniden türetmek yerine kontrol edebilir.

Uygulama denediğiniz her boyutta çalışıyorsa, sayıları ayarlamayı bırakın ve çalışan hizmeti başarısız olandan ayıran ilkeye bakın.