OpenVPN evde çalışıyor ama bir ağda çalışmıyor: UDP mi TCP mi?

Aynı profil evden bağlanıyor, otel, kampüs veya şube ağında duruyor. Kimlik bilgileri değişmedi, dolayısıyla ilginç değişken yol: OpenVPN paketleri okumadan önce onlara ne oluyor. Dört olası nedeni test edilebilecekleri sırayla karşılaştırmak, sertifikalar hakkında tahmin yürütmekten iyidir. Her biri farklı bir iz bırakır ve iz onları ayıran şeydir.

Hangi aşamanın başarısız olduğu hangi karşılaştırmanın önemli olduğunu söyler

İstemci günlüğü ne kadar ilerlediğinizi zaten kaydeder. TLS anahtar anlaşmasının zaman aşımı içinde gerçekleşmediğini söyleyen satır, ilk paketin çıktığını ve kullanılabilir bir yanıtın dönmediğini gösterir, bu da yolu işaret eder. Sertifika reddi tamamen farklı görünür: bir yanıt gelir, ardından belirli bir doğrulama hatası nedeni adlandırır. Yeniden deneme döngüsünden önceki son satırı not edin, çünkü ağlar arasında karşılaştırdığınız değer odur.

Sonradan değil, yeniden denerken yakalayın. İstemcide tcpdump -ni any udp port 1194 herhangi bir yanıtın geri gelip gelmediğini gösterir. Kontrol ettiğiniz bir sunucunun WAN arayüzünde tekrarlayın; bu, o paketlerin uzak uca ulaşıp ulaşmadığını ortaya koyar.

Tek yönlü trafik burada mevcut en faydalı sonuçtur, çünkü aralıklı bir şikâyeti araştırma yönüne dönüştürür. Yakalama dosyalarını saklayın, çünkü aynı sorunun bir sonraki bildirimi bir açıklamadan çok kanıtla kapatılır.

UDP filtreleme ile kapalı bağlantı noktası

Birçok erişim ağı sürekli UDP'yi şüpheli bulur ve bazı İSS'ler onlarla aynı fikirdedir. Kapalı bir bağlantı noktası istemci tarafında aynı sessizliği üretir. Fark seçiciliktir: bir filtre hangi hedefleri veya bağlantı noktalarını düşürdüğü konusunda seçicidir, kapalı bir bağlantı noktası ise o bağlantı noktasına yönelen her şeyi reddeder.

443 bağlantı noktasındaki TCP profili olağan çözümdür, çünkü sıradan bir HTTPS akışına benzer ve çoğu captive portal ve çıkış filtresinden geçer. İki koşul sağlanmalıdır. Sunucu proto tcp-server ile dinlemeli, istemci proto tcp-client ile eşleşmeli ve operatör o alternatif uç noktayı yayımlamalıdır. Çalışan bir UDP profilini TCP 443 diye yeniden yazmak, diğer uçta kimse dinlemiyorsa hiçbir yere varmaz.

Kapalı bağlantı noktası bir yapılandırma sorunudur, sansür sorunu değil. Ev yönlendiricisinin arkasındaki sunucunun UDP bağlantı noktasının yönlendirilmesi gerekir ve yönlendiricinin güvenlik duvarı buna izin vermelidir. Bağlantı noktasına hiç izin verilmediyse, kimlik bilgilerinden bağımsız olarak her istemci anlaşmada başarısız olur ve hata ağı değil sunucuyu izler.

Eski protokoller bu eksende kötü karşılaştırılır. PPTP, TCP 1723 artı GRE gerektirir ve GRE bir bağlantı noktası değil IP protokolü 47'dir, bu yüzden sıradan bir bağlantı noktası yönlendirmesi bunu ifade edemez.

Paketleri düşüren anahtar olduğunda

Yönetilen bir anahtar tüneli bilerek düşürebilir. Bazı HPE ve Aruba modelleri gelişmiş güvenlik bölümlerinde, bazen Prevent UDP Blat Attack olarak etiketlenen bir UDP taşkın koruma denetimi sunar. Bu denetim etkinleştiğinde anahtarın arkasındaki sunucu hiçbir şeye yanıt vermez ve her istemci aynı şekilde zaman aşımına uğrar. Denetimi kaldırıp çalışan yapılandırmayı kaydetmek onarımın tamamıdır, ancak yalnızca anahtarın gerçekten yolda olduğunu kanıtladıktan sonra.

Anahtarın düşürmesini sağlayıcı engellemesinden ayıran şey karşı kanıttır. İSS'ye kayıt açmadan önce arayüz sayaçlarını ve taşkın koruma günlüğünü okuyun. DoS veya taşkın korumalı tüketici yönlendiricileri aynı biçimde başarısız olur ve kısa UDP boşta kalma zaman aşımı olan her ara kutu da öyle. Hiç tamamlanmayan el sıkışma bir düşürmeye işaret ederken, birkaç dakika sessizlikten sonra ölen tünel zaman aşımına işaret eder.

Profil değiştirmeden önce istemci ile sunucu arasındaki her aygıtı yazın. Yanlış katmanda uygulanan bir düzeltme bir sonraki ağa kadar doğru görünür. Bu liste ayrıca bir sonraki mühendise tüm araştırmayı tekrarlamadan nereye bakacağını söyler.

DNS hatası gibi görünen bir adres örtüşmesi

10.0.0.0/8 içinde numaralandırılmış bir erişim ağı tünel havuzuyla örtüşebilir ve çözümleyici genellikle o havuzun içinde yaşar. Bir dizüstü bilgisayar Wi-Fi'de 10.184.178.50 gibi bir adresi /8 maskesiyle aldığında, her 10.x hedefi tanım gereği yereldir. 10.4.0.1 için paketler sonra LAN'a gider, tünel ayakta kalır ve ad çözümlemesi başarısız olur.

ip addr örtüşmeyi bir bakışta ortaya koyar ve ip route get 10.4.0.1 paketin gerçekte nereye teslim edileceğini gösterir. Görünen belirti bir çözümleyici hatası olduğu için bu, çoğu zaman birkaç tur DNS değişikliğinden sağ çıkar.

Havuzu yeniden numaralandırın veya o erişim ağını kapsam dışında tutun. Hiçbir istemci tarafı ayarı örtüşmeden kurtarmaz.

TCP yedeği ile yol düzeltmesi arasında seçim

Yolu kontrol etmiyorsanız ve kullanıcıların bugün çalışması gerekiyorsa TCP yedeğini seçin ve maliyetlerini kabul edin: TCP içinde TCP, kayıplı bağlantılarda kötü davranır ve yedek, sizin işlettiğiniz bir dinleyici gerektirir. Engelleme size ait altyapıdaysa yol düzeltmesini seçin, çünkü bir güvenlik duvarı kuralı ikinci bir dinleyiciden daha ucuzdur. Her iki durumda da katmanları sırayla geçin: bağlantı, dış taşıma, anlaşma, iç yönlendirme. O ağda başarısız olan aşama önemli olan tek gerçektir.

Sonucu kullanıcıya göre değil ağa göre kaydedin. Aynı hatanın bir sonraki bildirimi o zaman sertifika teorisinden değil bilinen bir aşamadan başlar. Bu kayıt ayrıca, gerekirse kalıcı bir ikinci dinleyiciyi haklı çıkaran şeydir.