VPN olmadan Git takılıyor mu? OpenSSH paketleri IPQoS ile işaretliyor

Ofisten alınan klon çalışıyor, aynı klon telefon hotspotu üzerinden çalışıyor ve aynı klon bir otel ağından VPN açılana kadar askıda kalıyor. SSH el sıkışması tamamlanıyor ve oturum ilk gerçek aktarımda sessizleşiyor. İstemci yapılandırmasına eklenen tek bir satır git ve ssh'ı birlikte iyileştiriyor. Tek bir istemci ayarı birden çok aracı aynı anda onardığında, hata istemcinin gönderdiği şeyde, gönderdiği bağlantıda değildir.

Belirtiyi bir yönlendirme farkı olarak okuyun

Bir sorunu iyileştiren tünel nadiren onarımdır. Rotayı, taşıyıcıyı ve aradaki cihazları değiştirir, dizüstü bilgisayar ise tam olarak aynı paketleri üretmeye devam eder. Bir rota başlığı yanlış işlerken diğeri onu değiştirmeden geçiriyorsa, fark aradaki cihazın politikasındadır, istemcide değil. Burada tünel bir tanıktır, çözüm değil.

Oturumun öldüğü nokta bunu daha da daraltır. Ad aramada veya anahtar değişiminde başarısız olan hiçbir şey böyle görünmez. Kimlik doğrulayıp bir banner yazdıran ve ardından ilk büyük yazmada donan bir oturum, yönlendirme, adlar ve kimlik bilgilerinin hepsinin çalıştığını zaten kanıtlamıştır.

İstemci her SSH soketine bir QoS baytı basar

7.8'den itibaren her OpenSSH bağlantısı IP başlığında yönlendiricilerin trafiğe öncelik vermek için kullanabileceği bir değer taşır. Terminal oturumları bir değer alır, toplu kopyalar başka bir değer alır; yazan bir insanın dosya aktarımından daha iyi muameleyi hak ettiği teorisine göre. Çoğu ağ bu ipucunu tamamen yok sayar, bu yüzden yıllarca fark edilmez. Wi-Fi sürücülerinin, mobil operatörlerin ve VPN yoğunlaştırıcılarının küçük bir kısmı buna göre davranır ve bazıları kötü davranır.

Bu değer akışın ortasında yeniden yazıldığında veya atıldığında bağlantı başarısız olmaz, ilerlemeyi durdurur. Yeniden gönderimler artar, pencere çöker ve uygulama hiçbir şey bildirmez çünkü hiçbir şey hata döndürmemiştir. İnsanların belirtiyi arıza yerine takılma olarak tanımlamasının nedeni bu sessizliktir.

Önce ssh -V ile istemci sürümünü doğrulayın. 7.8 veya üzeri her sürüm bu davranışı varsayılan olarak taşır.

Bunu MTU ve DNS'ten ayıran üç komut

Herhangi bir yapılandırma dosyasını düzenlemeden önce iki benzer nedeni dışlamak gerekir. MTU arızası küçük alışverişleri geçirir ve ilk büyük pakette donar, ad arızası ise hiçbir zaman oturum oluşturmaz.

ssh -o IPQoS=none -v [email protected]
ssh -G [email protected] | grep -i ipqos
sudo tcpdump -ni any -vv "tcp port 22"

İlk komut başarısız işlemi işaret kapalıyken yineler ve başarılı çalışması mevcut en güçlü tek kanıttır. İkincisi istemcinin o hedefe gerçekten uygulayacağı yapılandırmayı yazdırır, bu da unuttuğunuz bir dosyadaki eski kaydı yakalar. Üçüncüsü aktarım takılıyken TOS baytını iki yönde gösterir ve ilginç desen bozuk rotada bir değer olması, çalışan rotada ise hiç olmamasıdır.

Kaydı sunucuda değil dizüstü bilgisayarda yapın, çünkü değeri gönderen taraf belirler ve her iki yön de onu değiştirebilir. Çalışan ve başarısız rotayı aynı kayıtla karşılaştırın, fark tahmin yürütmeden ortaya çıkar.

İstisnayı tek bir dosyaya koyun, her seferinde tek bir ana makine

Bir istisna, uygulandığı ana makinenin yanında olmalı ve neden var olduğunu söyleyen bir yorum taşımalıdır.

Host gitlab.example.internal
    IPQoS none
    # direct route rewrites the marking; the tunnel route passes it

Kapsam, değerin kendisinden daha önemlidir. Joker karakterli bir kayıt davranışı her yerde kapatır, iyi davranan ağlarda yardımcı olan bir ipucunu atar ve kimsenin ne zaman ortaya çıktığını söylemesine izin vermez. Ana makine başına kayıt okunabilir, geri alınabilir ve ağ onarıldıktan sonra silinmesi son derece kolaydır. Kişisel bir geçici çözüm için kullanıcı dosyasını, tüm bir filo aynı istisnaya ihtiyaç duyduğunda ise yönetilen dosyayı kullanın.

İstisnanın neleri kapsamadığı konusunda açık olun. SSH için geçerlidir, bu nedenle HTTPS uzak deposu, paket aynası ve tarayıcı hepsi dışında kalır ve bunlardan herhangi birindeki bir arıza kendi kanıtını gerektirir. Bir bastion üzerinden geçen zincirde her sıçrama istemci yapılandırmasını kullanır ve takılan sıçrama sınırlandırmaya değer olandır.

Döngüyü ağ sahibiyle kapatın

Bulguyu dört gerçek olarak teslim edin: istemci sürümü, test edilen rota, kullanılan VPN istemcisi ve işareti hangi yönün taşıdığı. Bu dördü bir ağ sahibinin muameleyi yeniden üretmesi ve kasıtlı olup olmadığına karar vermesi için yeterlidir.

İstisna takılmayı iyileştirmiyorsa kaldırın. Başarısız bir deneyden sağ çıkan geçici çözüm folklor olur ve bir sonraki kişi hiçbir işe yaramadığını kanıtlamak için bir saat harcar. İyileştiriyorsa, yol onu geçen her diğer araç için hâlâ yanlıştır ve onarım aradaki cihazı işleten kişiye aittir.

İstemcideki değişiklik son kullanma tarihi olan bir geçici çözümdür. O tarihi yoruma yazın.