OpenConnect sayfaları neden tünelin MTU'sunu düşürene kadar takılır

Giriş başarılı olur, portalın ana sayfası çizilir ve ardından bir gösterge paneli bileşeni ya da rapor, tarayıcı pes edene kadar waiting for host durumunda kalır. Herkese açık siteler tüm bu süre boyunca normal yüklenir ve hiçbir kimlik bilgisi değişmemiştir. Küçük yanıtların gelip büyüklerin takılması, erişim kuralının değil paket boyutu tavanının işaretidir. Profilde başka bir şeyi değiştirmeden önce bu okumayı doğrulayın.

Boyut sorununu ilke sorunundan ayırın

Reddedilme olasılığını dışlayarak başlayın. Ağ geçidi sizi reddetseydi, bağlantı sayfayı yarım yüklemek yerine hemen başarısız olurdu. Ayağa kalkıp yalnızca daha büyük aktarımlarda takılan bir tünel, dış yolun iç paketi taşıyamadığını söyler.

Mekanizma kapsüllemedir. Her iç paket tünel başlıkları kazanır, böylece fiziksel bağlantıya sığan yük artık sığmayan bir dış pakete dönüşür ve do-not-fragment bitini taşıyan her şey, tarayıcının yorumlayabileceği bir yanıt olmadan atılır.

Tavanı do-not-fragment sondalarıyla ölçün

Tahmin etmek yerine tavanı ölçün. Parçalanmayı reddeden sondalar gönderin ve bir yanıt gelene kadar yükü adım adım düşürün, şöyle bir komutla başlayın: ping -M do -s 1472 host. DF ayarlıyken parçalanma gerektiğinden yakınan bir yanıt, değerin hâlâ çok yüksek olduğu anlamına gelir. 1462'de, sonra 1452'de yineleyin ve yanıt veren ilk boyutta durun. Sayıyı test ettiğiniz ana makineyle birlikte yazın, çünkü yanıt o yola aittir, genel olarak protokole değil.

Tünelin gerçekte trafik gönderdiği adresi test edin. Ağ geçidinin genel adına karşı dış sonda ve iç sunucuya karşı iç sonda farklı atlamaları ölçer ve herhangi birindeki ICMP filtrelemesi sağlıklı bir yolu bozuk gösterebilir.

Değeri tünel aygıtına uygulayın

Sonucu Wi-Fi bağdaştırıcısına değil, istemcinin oluşturduğu arayüze uygulayın. Linux istemcisinde bu ip link set dev tun0 mtu 1300 ve ardından değerin alındığını doğrulamak için ip link show tun0 olur. İstemcinin bildirdiği aygıt adını kullanın, çünkü bu ada uygulamaya ve tünelin nasıl kurulduğuna göre değişir.

Tünelin MTU'sunu düşürmek her paketin taşıdığı yükü küçültür, bu yüzden toplam verim biraz düşer ve büyük yanıtları kara deliğe göndermemenin bedeli budur. Daha küçük bir sayı otomatik olarak daha güvenli değildir. Bunun yerine fiziksel bağdaştırıcıyı değiştirmek hasarı o bağlantıdaki her oturuma yayar, aşırı büyük iç paketler ise aynı ölçüde büyük kalır.

Önce istemcinin kendi MTU isteklerini kullanın

Çağrıyı siz yönettiğinizde istemci sonradan yamalanmak yerine bir boyut isteyebilir. --mtu sunucudan bir tünel MTU'su ister ve --base-mtu altındaki yolun MTU'sunu bildirir, böylece ağ geçidi tünel sayısını türetebilir. İkisi de istektir ve istemcinin kılavuzu ağ geçidinin bunlardan birini yerine getireceğini vaat etmez.

Bu ayrım çalışma sıranızı belirler. Önce isteği deneyin ve ürettiği arayüzü inceleyin, sonra ağ geçidinin seçtiği değer hâlâ takılıyorsa aygıtı yerel olarak ayarlamaya dönün.

Başarısız olan aktarımla doğrulayın, sonra kalıcı hale getirin

Yerel bir ip link değişikliği, istemci tüneli yeniden kurana kadar sürer; bu, sonraki yeniden bağlanmada veya devam etmede olur. Değeri bağlantının başladığı yere koyun: istemciyi çalıştırıp sonra aygıtı ayarlayan bir sarmalayıcı, ExecStartPost adımı olan bir systemd birimi veya ağ geçidi kabul ettiğinde istemci seçeneği. Profilin yanında sürüm denetiminde tutun ki sonraki kişi sayının neden orada olduğunu görsün.

Başarısız olan istekle test edin, ana sayfayla değil. Raporu açın, eki indirin veya takılan depo alımını çalıştırın ve hâlâ takılıyorsa tam olarak nerede durduğunu not edin. Değişiklikten sonra çizilen sayfa çok az şey kanıtlar, çünkü önceden de çiziliyordu.

Aynı aktarım aynı noktada takılıyorsa, MTU kuramı kanıtlanmamıştır. Tünelde trafiği yakalayın ve sayıyı yeniden değiştirmeden önce hangi tarafın göndermeyi bıraktığını kontrol edin, önceki değeri de yazılı tutun ki geri alma tek komut olarak kalsın.