Bir OpenVPN profili neden evde çalışırken otelde başarısız olur

Ofis Wi-Fi'si ile bir otel odası aynı dizüstü bilgisayara çok farklı iki ağ verebilir ve aradaki profilin bundan haberi yoktur. Evde çalışan şey müsait bir üst bağlantı, çalışan ad çözümlemesi ve tünelin taşıdığı hiçbir şeyle çakışmayan yerel bir alt ağ varsayar. Bu varsayımların her biri ayrı ayrı bozulabilir.

Bunu ayıklamanın faydalı yolu ağı dört ayrı gerçek olarak ele alıp sırayla test etmektir. Önce profil hakkında tahmin yürütmek genellikle hiçbir şeyi düzeltmeyen ve kanıtları gizleyen bir değişiklik üretir.

Dört ağ gerçeği konuma göre değişir

İlk gerçek, yerel ağın sizi hiç dışarı çıkarıp çıkarmadığıdır. Bir giriş portalı cihazı bir giriş sayfasına alır ve o sayfa tamamlanana kadar diğer her şeyi engeller, yani profil ne kadar doğru olursa olsun tünel başlayamaz.

İkincisi ad çözümlemesidir. DNS'i araya giren bir portal her sorguya kendi adresiyle yanıt verir, bu yüzden VPN sunucu adı portala çözümlenir ve istemci bir web sayfasına tünel kurmaya çalışır.

Üçüncüsü taşıma filtrelemesidir. Yalnızca gezinmeye izin vermek isteyen ağlar TCP 443'ü rastgele hedeflere geçirir ve UDP dahil neredeyse her şeyi düşürür.

Dördüncüsü adreslemedir. Yerel alt ağ tünelin arkasındaki bir ağla çakışabilir veya üst bağlantı hiçbir kullanılabilir IPv4 yolu sunmayabilir.

Ad çözümlemesi ve giriş portalı

Profildeki sunucu adını sunucunun sayısal adresiyle değiştirip tekrar deneyin. IP bağlanıp ad bağlanmıyorsa suç ad çözümlemesindedir ve profilin kendisi iyidir.

VPN'e dokunmadan önce bir tarayıcı açıp sıradan bir HTTP sayfası deneyin. Giriş sayfasına yönlendirme, portalın hâlâ beklemede olduğu anlamına gelir; tamamlayın ve sonra yeniden bağlanın. Birçok otel birkaç saat sonra oturumu da sonlandırır, bu da giriş sorunu gibi değil gün ortasında kopma gibi görünür.

Sayısal adres de başarısız olursa ad çözümlemesi açıklama değildir, bu yüzden taşımaya geçin. Test ettiğiniz adresi saklayın, çünkü bir sonraki kontrolün paketlerin makineden çıkıp çıkmadığını söyler.

Taşıma filtrelemesi: önce UDP, yedek olarak TCP 443

UDP 1194 üzerinden bir OpenVPN akışı bir otel güvenlik duvarının tanıdığı hiçbir şeye benzemez, bu yüzden hatasız olarak düşürülür. İstemci zaman aşımı dolana kadar yeniden dener ve kullanıcı ret yerine hiç kurulmayan bir bağlantı görür. Böyle davranan güvenlik duvarları düşürmeyi görebileceğiniz bir yerde nadiren günlüğe kaydeder. Ret olmaması kendi başına ipucudur.

TCP 443 güvenilir yedektir çünkü ağ onu sıradan HTTPS'ten ayırt edemez. Varsa operatörün TCP profilini kullanın, çünkü sunucunun da o taşıma ve bağlantı noktasında dinlemesi gerekir; yalnızca istemciyi değiştirmek farklı türde bir hataya yol açar. TCP profili yoksa bağlantı noktasını düzenleyerek yenisini uydurmak yerine operatöre sorun. Sunucu tarafı da aynı fikirde olmalıdır ve uyumsuzluk yine güvenlik duvarı sorunu gibi görünür.

Bir performans bedeli bekleyin. TCP içinde TCP kayıplı bir bağlantıda yeniden iletimleri artırır, bu yüzden çalışan bir TCP tüneli tıkalı bir otel ağında yine de yavaş hissedilebilir. Bu erişilebilirlik için bir takas, peşine düşülecek bir kusur değil.

Adres çakışmaları ve IPv4'süz üst bağlantılar

Bir tünel kurulup yine de hiçbir şey taşımayabilir. Yerel LAN ile uzak bir ağ 192.168.1.0/24 gibi bir öneki paylaştığında istemci uzak ana bilgisayarı doğrudan bağlı sayar ve paketi tünel yerine yerel bağlantıya gönderir. Belirti, ulaşılamayan bir alt ağla kurulan başarılı bir bağlantıdır ve bu, sunucu tarafındaki bir yönlendirme sorunu olarak kolayca yanlış okunur.

Kalıcı düzeltme, uzak LAN'ı sıra dışı bir özel aralığa taşımaktır. Evde kimsenin kullanmadığı bir aralık seçmek, örneğin 10.42.0.0/24, sorunu bir yerine her gelecek konum için önler. Yerel geçici çözüm o otelden, hotspot'tan veya yönlendiriciden kaçınmaktır ki bu hiç de düzeltme değildir.

Mobil üst bağlantılar iki varyasyon ekler. Operatör düzeyinde NAT, gelen bağlantıların ulaşmadığı anlamına gelir; bu, sunucu barındırıyorsanız önemlidir ama giden bir istemci için değildir. NAT64 çevirisiyle yalnızca IPv6 olarak yapılandırılmış bir APN, gerçek bir IPv4 yolu isteyen bir istemciyi başarısız kılabilir ve olağan çare APN protokolünü IPv4 veya çift yığına değiştirmektir.

Tünel ayağa kalktıktan sonraki belirtiler

Bağlanıp sonra sessizleşen bir tünel genellikle keepalive veya MTU sorunudur, engellenmiş bir bağlantı noktası değil. Belirli sayıda dakika sonra düşen bir bağlantı keepalive veya yeniden müzakere zamanlayıcısına işaret eder. İstemciyi eşini yoklamaya ve yanıtlar durunca yeniden başlamaya ayarlayın; ping geçip büyük aktarımlar takılıyorsa daha küçük tünel MTU'sunu test edin.

Yardım istemeden önce üç şeyi yazın: denediğiniz adres ve yanıt verip vermediği, kullandığınız taşıma ve bağlantı noktası, ve başarısız olan ağın yerel alt ağı. Birlikte bunlar ad çözümlemesini taşıma filtrelemesinden ve adres çakışmasından ayırır; kanıtla temas ettiğinde ayakta kalan nedenler bunlardır.