Sayfalar açılıyor ama VPN'de yüklemeler takılıyor: hangi neden kazanır
Boyuta bağlı bir takılma, yol MTU arızasına uyar; ayrıca DNS, uygulama sınırı veya kararsız bir tünele de uyar. Dört gözlem hangisi olduğuna karar verir.
Sayfalar açılıyor, VPN bağlı olduğunu bildiriyor ve dosya yüklemesi her seferinde aynı noktada donuyor. Bu tanıma dört açıklama uyuyor: paket boyutu sorunu, ad çözümleme sorunu, uygulama sınırı ve sürekli sıfırlanan bir tünel. Her biri farklı bir gözlemle doğrulanabilir veya dışlanabilir, bu yüzden karar nedeni tahmin etmek değil, doğru testi seçmektir.
Dört aday ve tek bir biçim
Arızanın biçimiyle başlayın, çünkü herhangi bir araç açılmadan önce listenin büyük kısmını eler. Sabit bir boyutta oluşan takılma tersi kanıtlanana kadar boyut sorunudur. Rastgele noktalarda oluşan takılma kayıp veya kararlılık sorunudur. Bağlantı açılmadan önceki arıza ad sorunudur.
Dördüncü aday uygulamanın kendisidir. Yükleme sınırları, istek zaman aşımları ve proxy'deki gövde boyutu üst sınırları, tarayıcıdan ağ arızası gibi görünen arızalar üretir ve bunlar genellikle takılma değil, ret olarak gelir.
Herhangi bir şeyi test etmeden önce gözlenen biçimi yazın. "Her seferinde yaklaşık aynı bayt sayısında, tünel ayaktayken duruyor" ifadesi "yüklemeler çalışmıyor" ifadesinden çok daha güçlü bir başlangıç noktasıdır.
Sonra test ederken yolu sabit tutun. Çıkışı, protokolü ve sunucuyu aynı anda değiştirmek, hiçbirine atfedemeyeceğiniz bir sonuç verir. Koşu başına tek değişken, ve onu yazın.
Politikaya dokunmadan önce boyutu ikiye bölün
En ucuz ayırıcı, tek bir sayıyı değiştiren bir sonda. Hedefe artan boyutta, parçalanması yasak ping'ler gönderin, kontrol ettiğiniz dosyayı aynı hizmete yükleyin ve her birinin nerede durduğunu karşılaştırın.
ping -M do -s 1472 203.0.113.9
curl -T ./probe.bin -o /dev/null -w '%{size_upload} %{time_total}
' https://example.net/uploadİlk komut, tam boyutlu bir paketin yoldan geçip geçmediğini bildirir. MTU 1500 bayt iken parçalanmayan en büyük ICMP yükü 1472 bayttır ve tünel, iç paket başlamadan önce bu bütçeden daha fazlasını alır. İkincisi, uygulama düzeyinde bir aktarım için boyut ve süre verir ve gerçekten önemli olan sayı budur.
| Candidate | Observation that confirms it | Observation that rules it out |
|---|---|---|
| Path MTU or blocked ICMP feedback | Stall at a consistent size; large do-not-fragment probes fail | Small and large transfers both complete |
| Name resolution | The connection never opens for that name | The connection opens and then stalls mid-transfer |
| Application or proxy limit | A clean rejection at a documented size | No log entry on the server at all |
| Tunnel instability | Reconnects or rekeying during the transfer | The tunnel uptime is unchanged across the failure |
İkisini birlikte okuyun. Eşiğin üzerinde başarısız olan sondalar ve aynı eşiğe yakın duran bir yükleme tutarlı bir hikâyedir. Tüm sondalar başarılıyken yükleme, yolun açıkça taşıdığı bir bayt sayısında takılıyorsa bu uygulamaya veya sunucuya işaret eder ve hiçbir MTU çalışması bunu değiştirmez. Bu olumsuz sonuç, olumlu bir sonuç kadar değerlidir. Soruşturmanın en pahalı dalını ortadan kaldırır.
Sonra aktarım sırasında kararlılığı kontrol edin, çünkü büyük bir yüklemenin ortasında anahtarı yenileyen bir tünel, boyuta bağlı görünen ama olmayan bir arıza üretir. Çalışma süresi okuması bunu doğrulamanın en ucuz yoludur.
Onarım ile geçici çözüm arasında seçim yapın
Kanıtlar boyuta işaret ediyorsa iki dürüst yanıt ve bir dürüst olmayan yanıt vardır. Dürüst olanlar, gerekli ICMP geri bildirimine izin vererek yol MTU keşfini geri getirmek veya duyurulan segment boyutunu sınırlayarak eşlerin daha küçük segmentler göndermesini sağlamaktır. Dürüst olmayan, bir arayüzün MTU'sunu forumdan kopyalanmış bir değere düşürmek ve neyi değiştirdiğini hiç doğrulamamaktır.
Seçim neyi kontrol ettiğinize bağlıdır. İşlettiğiniz bir ağda ICMP mesajlarına izin vermek daha temiz düzeltmedir, çünkü mekanizmayı her protokol için çalışır durumda tutar. Kontrol etmediğiniz bir yolda sınırlama pratik seçenektir ve tüm sunucuya değil, dar biçimde uygulanmalıdır.
Kanıtlar uygulamaya işaret ediyorsa uygulamayı veya proxy yapılandırmasını düzeltin. 413 yanıtı ve askıda kalan bağlantı farklı arızalardır ve ikincisi genellikle kendi sınırları olan bir proxy içeren bir zincirde bir yerde zaman aşımıdır.
Her durumda, özgün değerleri saklayın ve geri aldıktan sonra yeniden test edin. Başarılı bir aktarımla çakışan bir değişiklik, onu tetiklediğinin kanıtı değildir ve geri alabilme yeteneği tanıyı tesadüften ayıran şeydir.
Kararı bir sonraki olaya kadar yaşayacak şekilde kaydedin
Dört olgu yeterlidir: gözlenen arıza biçimi, sondaların sonuçları, yaptığınız değişiklik ve yeniden testin sonucu. Bunlarla bir sonraki kişi sorunun aynı mı yoksa aynı belirtili yeni bir sorun mu olduğunu söyleyebilir.
Yolun bağlamını da not edin, çünkü MTU bulgusu belirli bir bağlantıya özgüdür. Evde çalışıp otelde başarısız olan bir dizüstü bilgisayarın iki yolu vardır ve birine uygulanan düzeltme diğeri hakkında hiçbir şey söylemez.
Son olarak, "VPN yüklemeleri bozdu" özetine karşı koyun. Tünel hem çalışan hem de başarısız durumda mevcuttu; değişen, yolun taşımak zorunda olduğu paketin boyutu veya aktarımın durdurulduğu yerdi. Gerçek mekanizmayı adlandırmak notu yararlı kılan şeydir.