VPN evde bağlanıyor ama otel Wi-Fi'sında zaman aşımına uğruyor

Dizüstü evdeki Wi-Fi'ya bağlanır, istemci üç saniyede bağlanır ve aynı profil bir saat sonra otelde başarısız olur. Arada hiçbir şey güncellenmedi. Bunu önünüzde bir müşteriyle gözden geçirmek, çoğunlukla hangi hatanın hangi aşamaya ait olduğunu bilmekle ilgilidir, çünkü yararlı bilgi istemcinin yazdırdığı koddadır, başarısız olmasında değil. Aşağıdaki dört adımı sırayla uygulayın, sizi bir adın, bir paketin, bir bağlantı noktasının yoksa bir ilkenin mi reddettiğini bileceksiniz.

Hata kodunu bir aşama olarak okuyun, hüküm olarak değil

İstemci bir tünel oluşmadan önce üç ayrı aşamaya ulaşır. Sunucu adını çözer, ağdaki bir şeyden yanıt alır ve bir güvenlik ilişkisi üzerinde anlaşır. Her aşamanın kendi hata iletisi vardır ve özellikle Windows, hangi aşamaya ait olduklarını bildiğinizde farklı kodlar konusunda cömerttir.

Bu kodlardan ikisi ağın suçsuz olduğunu gösterir. 789, paketlerin aktığını ve iki ucun şifreleme konusunda anlaşamadığını gösterir; bu, evde düzeltebileceğiniz bir yapılandırma sorunudur. 868 ise hiçbir paketin dışarı çıkmasına gerek olmadığını gösterir, yani ad çözülene kadar tünelin tasarımı önemsizdir. Kodu doğru aşamaya yerleştirmek herhangi bir yakalamadan daha çok zaman kazandırır, çünkü sonraki üç adımdan hangisini atlayacağınızı söyler.

İstemci Windows değilse uygun ölçüde dikkatli olun. Üçüncü taraf istemciler bunların çoğunu "bağlantı başarısız" diye özetler, bu yüzden sonraki iki adım iletiye hiç güvenmez.

Tüneli suçlamadan önce adı denetleyin

Otel ve havaalanı ağları DNS'i sürekli yakalar ve portal adresiyle yanıt veren bir çözümleyici, ölü bir sunucuya tam olarak benzeyen bir hata üretir. Yerel çözümleyicinin söylediğini bir genel çözümleyicinin söylediğiyle karşılaştırın:

Resolve-DnsName vpn.example.net -Type A
nslookup vpn.example.net 1.1.1.1
ipconfig /all | findstr /i "DNS Servers"

İki yanıt farklıysa yönlendiriliyorsunuz ve bu çözülene kadar teşhisin geri kalanı boşa gider. Özellikle portal adresi TCP bağlantısını memnuniyetle kabul eder ve sonra takılır, bu yüzden tarayıcıyla test ederken güvenlik duvarı engeli gibi görünebilir.

Şimdi ulaşmak istediğiniz adresin kullanılan adres olduğunu doğrulayın. Bazı istemciler önceki çözümü profilin tüm ömrü boyunca önbelleğe alır, bu yüzden DNS değişikliğinden sonra yeniden bağlanma yine eski adrese gider. Yeniden test etmeden önce istemciyi tamamen kapatın, aynı pencerede bağlantıyı kes ve bağlan düğmelerine basmak yerine.

Hangi dış paketin kaybolduğunu bulun

Tünelin, seninle sunucu arasındaki yola tamamen ait bir dış akışı vardır ve ara kutuların sınıflandırıp düşürdüğü akış tam olarak budur. Bunu istemcide yakalayın, sonra çalışan bir ağı başarısız olanla karşılaştırın. Windows'ta ilk bakış için yerleşik yakalama yeterlidir:

pktmon filter remove
pktmon filter add -p 500 -t UDP
pktmon start --capture --pkt-size 128
pktmon stop
pktmon etl2txt PktMon.etl

Görmek istediğiniz, paketlerinizin gerçekten çıkıp çıkmadığı ve bir şeyin geri dönüp dönmediğidir. Dışarı giden paketlere hiçbir yanıt gelmemesi, yolun veya uzak ucun onları düşürdüğünü gösterir; hiçbir şey çıkmıyorsa istemci göndermeye hiç ulaşmadı, bu da ad çözümüne veya yerel bir güvenlik duvarı ilkesine işaret eder.

Aynı testi bir telefon hotspot'unda tekrarlayın. Bu, elinizdeki en bilgilendirici karşılaştırmadır, çünkü dizüstünü, istemciyi ve kimlik bilgilerini aynı tutarken oteldeki her kutuyu yoldan çıkarır. Hotspot'ta tünel açılırsa sunucuya bakmayı bırakın. Orada da başarısız olursa, ağın hiç neden olmadığı bir istemci veya hesap sorununuz var.

Bir taşımayı değiştirip yeniden test edin

Dış akışın düşürüldüğünü bildiğinizde pratik soru, ağın hangi akışa izin verdiğidir. Çoğu kısıtlı ağ, aksi hâlde çalışamayacağı için giden TCP 443'e izin verir, bu yüzden dinleyiciyi oraya taşımak olağan yanıttır. OpenVPN üzerinde bu, sunucu değiştirilene kadar istemci tarafında bir anahtardır:

openvpn --config corp.ovpn --proto tcp-client --remote vpn.example.net 443 --verb 4

IPsec istemcilerinin kendi ayar panellerinde eşdeğer bir anahtarı vardır, genellikle TCP üzerinden IPsec veya NAT geçişi olarak tanımlanır. Onu değiştirmek de bir teşhistir: tünel TCP üzerinden açılıp UDP üzerinden ölürse, ağın UDP'yi filtrelediğini kanıtlamış olursunuz ve o siteye her gidişinizde gerekecek ayarı da bulmuş olursunuz.

İlk denemede yönlendirici özelliklerini kapatma cazibesine direnin. Bir otel ağında durum denetimini veya taşkın korumasını kapatmak zaten sizin için mümkün değildir ve kendi donanımınızda bunun yerine bir dizüstü için gerçek bir korumadan vazgeçersiniz. Hangi ayarın sonucu değiştirdiğini not edin, sonra onu geri koyun ve ağın zaten izin verdiği bir taşıma arayın.

Aynı profili ikinci ağda doğrulayın

Talebi kapatmadan önce, değişikliğin binadan çıktıktan sonra da sürdüğünü kanıtlayın. Özgün ağda özgün ayarlarla yeniden bağlanın, ilk otuz saniyeyi yakalayın ve istemcinin hotspot'ta ulaştığı durumun aynısına ulaştığını doğrulayın:

pktmon filter add -p 443 -t TCP
pktmon start --capture
Get-VpnConnection -Name "Corp" | Select-Object ConnectionStatus, TunnelType, ServerAddress

Son komutun ortaya çıkardığı ayrımı korumaya değer: profil bağlı bir tünel bildirebilir ama içindeki yönlendirme yanlıştır ve bu "VPN açık ama hiçbir şey çalışmıyor" sonucunu verir, ki bu başka bir makaledir. Düzenlemenizden sonra tünel türü değiştiyse, profil test ettiğiniz profil değildir.

Sonra bulguyu bir sonraki kişinin bakacağı yere yazın. "Kurumsal profil bu sitede TCP 443 gerektiriyor; UDP 500 otel tarafından filtreleniyor" bir meslektaşın harekete geçebileceği bir cümledir. "Otellerde VPN kararsız" öyle değildir ve aynı saatin gelecek ay yeniden harcanacağını garanti eder.