Yakalama portalı VPN'inizi neden engeller ve nasıl yeniden oturum açarsınız
Genel Wi-Fi, cihazınızı ondan tek bir paket çıkmadan önce yetkilendirir. Portal neyi atar, VPN'iniz bunu neden yanlış bildirir ve sizi yeniden hangi sırayla bağlar.
Açık bir ağda erişim noktanız paketleri internete öylece teslim etmez. Yukarıdaki bir politika noktası cihazınızın zaten yetkilendirilip yetkilendirilmediğini denetler ve yetkilendirilene kadar neredeyse her şey atılır. VPN istemciniz bu sessizliği ölü sunucu olarak okur. Bunu nadiren söyler: WireGuard el sıkışmayı boşluğa yineler, OpenVPN bağlantı zaman aşımını bildirir ve IKEv2 yanıt vermeyen uzak sunucu hakkında 809 hatasıyla döner.
Portal gerçekte neyi denetler
Yakalama portalı birbirine yapıştırılmış iki şeydir: politika karar noktası ve yönlendirici. Cihazınız ilişkilenip DHCP kiralaması aldığında ağ sizi yetkilendirme öncesi bir duruma koyar.
Bu durum bir güvenlik duvarı kural kümesidir. Genellikle DNS'e izin verir ve kısa bir portal ana bilgisayar listesine HTTP veya HTTPS'e izin verir, geri kalan her şeyi atar. İzin verilen liste duvarlarla çevrili bahçedir ve neredeyse hiçbir zaman VPN uç noktasını içermez.
Bu atmaların hiçbiri kibar değildir. VPN sunucusuna yönelen paketler reddedilmek yerine atılır, bu yüzden istemci ne ICMP unreachable ne TCP reset alır, yalnızca yanıtın yokluğunu alır. Üreticiye göre yönlendirici 80 numaralı bağlantı noktasına oturum açma sayfasına yönlendirmeyle yanıt verebilirken 443 numaralı bağlantı noktası atılır ya da yakalanır. Yönlendirmeler sıradan bir HTTP yanıtı taşıdığı için kolayca fark edilir; 443'teki yakalama tarayıcınızın güvenmeyi reddedeceği bir sertifika gerektirir.
Yetkilendirmenin kendisi genellikle cihazın MAC adresine, bazen kiralanan IP'ye bağlıdır ve zamanlayıcısı olan bir oturum tablosunda yaşar. Oturum açma bir kayıt oluşturur. Trafiğinizi geçiren güvenlik duvarı kuralı yalnızca o kayıt var olduğu sürece vardır ve bu yüzden sizin tarafınızda hiçbir şey değişmeden sorunun tamamı sonradan geri gelir.
VPN el sıkışması başlamadan neden ölür
Her protokolün kendi taşıması vardır ve yetkilendirme öncesi güvenlik duvarı her birini farklı bozar. Windows ve iOS'ta IKEv2 UDP 500 ve UDP 4500 üzerinden gider; bu bağlantı noktalarındaki atma 809 olarak ya da aşamaları ayrı bildiren istemcilerde ad çözümleme benzeri bir başarısızlık olarak görünür. UDP 1194 üzerinden OpenVPN zaman aşımına kadar bağlanıyor durumunda kalır. TCP 443 üzerinden OpenVPN ilginç durumdur, çünkü portal TCP el sıkışmasını tamamlayıp sonra kendi yönlendirme sayfasıyla yanıt verebilir, böylece zaman aşımı yerine TLS hatası görürsünüz.
WireGuard mekanizmayı en açık gösterir. Tasarım gereği yalnızca UDP'dir, TCP yedeği yoktur, bu yüzden bilinmeyen UDP'yi atan güvenlik duvarı taşımayı tamamen kaldırır. İstemci artan aralıkla el sıkışma başlatmaları göndermeye devam eder ve hiç tamamlanmayan bir el sıkışma bildirir. O iletide hiçbir yerde Wi-Fi anılmaz ve tarayıcı açmanız gerektiğine dair hiçbir şey ima edilmez.
Platformlar durumu VPN'inizden önce fark etmeye çalışır. Windows oturum açma bildirimini gösterip göstermemeye karar vermek için bilinen bir URL alır, Android 204 No Content yanıtı vermesi gereken uç noktayı ister ve Apple aygıtları küçük bir yakalama ağı penceresi açar. Bu yoklamalar işe yarar çünkü portal beklenen gövde yerine yönlendirmeyle yanıt verir. Aynı davranış portal tamamen sağlıklı görünürken tünelinizin ölü olmasını açıklar: yoklama ve tünel farklı kurallarla değerlendirilir.
Oturum süresinin bitmesi gerçekte neyi sıfırlar
Mekânlar oturumları VPN hesabınızla ilgisiz nedenlerle sonlandırır: hareketsizlik zaman aşımı, en uzun oturum süresi, yeni DHCP kiralaması veya başka bir erişim noktasına yeniden ilişkilenme. Zamanlayıcı çaldığında oturum tablosundaki kayıt kaybolur ve yetkilendirme öncesi kural kümesi giriş anındakiyle tamamen aynı biçimde geri gelir.
Kurulmuş bir tünel sağlıklı görünecek kadar uzun yaşar. Canlılık iletileri çıkmaya devam eder ve istemcinin bunu fark edip etmemesi yanıtsız trafiği nasıl ele aldığına bağlıdır, bu yüzden yol kaybolduktan sonra da durum ışığı bir süre yeşil kalabilir. Sonra tünel düşer ve her yeniden bağlanma denemesi aynı engellenen bağlantı noktalarında başarısız olur.
O anda istemci hatası, dikkatle okursanız hangi aşamada olduğunuzu söyler:
| Symptom | What it means | Next check |
|---|---|---|
| Handshake times out with no reply | Pre-authorization drop on UDP | Load any HTTP page and see whether the portal appears |
| Immediate TLS error on 443 | The portal answered your TCP connection | Authorize, then retry the same profile |
| Authentication rejected | Your credentials reached the server | The network is fine, so treat this as an account problem |
| Connects, then drops repeatedly | Session or lease churn | Watch the portal timer and the lease time |
Bir ayrıntı insanları yanıltır: oturum bir MAC adresine bağlıysa oturum açma sayfasını yeniden yüklemek işe yaramayabilir. İlişkilenmeyi bırakıp yeniden katılmanız gerekir, böylece portal süresi dolmuş bir deneme yerine yeni bir yetkilendirme denemesi görür.
Önce oturum açın, sonra tüneli kaldırın
İşleyen sıra şudur: cihazı yetkilendirin, yolu kanıtlayın, VPN'i başlatın, tüneli kanıtlayın ve ardından normal engellemenizi geri getirin. Son adım önemlidir çünkü portala ulaşmak için gereken geçici durum, bir öldürme anahtarının önlemek için var olduğu durumun ta kendisidir.
Tünel dışında engelleme seçeneği olan masaüstü istemcisi portal sayfasının yüklenmesi için duraklatılmalıdır ve hassas uygulamaları o tünel dışı pencerede kapalı tutmalısınız; yerel trafiğin korumasız çıktığı tek aralık budur. Yönetilen ve her zaman açık bir cihaz, sizin politikayı kaldırmanız yerine sahibinin yayımladığı yordamı kullanmalıdır. Portal bir sertifika uyarısı gösterirse durun: kabul etmek oturumunuzu mekânın yakalama vekil sunucusundan geçirir ve o vekil sunucu gönderdiğiniz her şeyi okuyabilir. Android'de her zaman açık VPN altındaki kilit, tünel kalkmadan önce trafiği engeller ve bazı derlemeler portal akışını hariç tutamaz; sizinki tutamıyorsa kilidi kapalı bırakmak yerine mekânın alternatif erişimini veya başka bir cihazı kullanın. Apple'ın istek üzerine kuralları, bir yoklama başarılı olana kadar tüneli reddedecek biçimde yazılabilir ve otel ağlarında istediğiniz davranış budur.
Zaten sahip olduğunuz araçlarla sırayla doğrulayın. Tünelden önce yoklamayı hem başlıklar hem gövde görünür biçimde çalıştırın ve VPN taşımanızın herhangi bir yanıt alıp almadığına bakın:
curl -sS -D - http://captive.apple.com/hotspot-detect.html -o -
sudo tcpdump -ni any 'udp port 500 or udp port 4500 or udp port 1194'
Yetkilendirmeden önce normal bir portal iki yanıttan birini verir: Location'ı oturum açma sayfasına işaret eden bir 302 veya portal sayfası olan HTML gövdesiyle bir 200. Hangisini aldığınızı not edin. Oturum açmadan önceki yönlendirme bir başarısızlık değildir; portal size nereye gitmeniz gerektiğini söylüyordur. Portal başarı bildirdikten sonra komutu yineleyin ve gövdesi harfi harfine Success kelimesi olan bir 200 bekleyin. Yoklamayı anlamlı kılan o dizedir. Siz hiç oturum açmadan önce ana bilgisayar normal yanıt veriyorsa bu ağda yakalama portalı yoktur. Yakalamada yetkilendirme öncesi atma, geri hiçbir şeyin dönmediği giden paketlerdir; çalışan bir yol ise aynı akışa yaklaşık bir saniye içinde yanıt gösterir. Bağlanın ve ardından yakalamayı yineleyin.
Portal evet dedikten sonra tünel hâlâ başarısız olursa
Oturum açma başarısı izin verilen taşımayla aynı şey değildir. Birçok mekân portala ve normal gezinmeye izin verirken UDP'yi tamamen engeller, bu da WireGuard ve UDP OpenVPN'i bozuk bırakır ve TCP 443 çalışır. TCP 443 geçip UDP geçmiyorsa bu yanlış yapılandırdığınız bir istemci değil mekânın politikasıdır, bu yüzden taşımayı değiştirin ya da sınırı kabul edip devam edin. Bundan sonra yeniden bağlanma hâlâ başarısız olursa tam hatayı saklayın; takıldığınız aşamayı adlandırır.
Diğer başarısızlıklar cihazda yaşar. Eski bir MAC'e bağlı kalmış oturum, kendi kiralaması olan ikinci bir Wi-Fi bağdaştırıcısı veya portalın sertifika istisnasını önbelleğe almış bir istemci, temiz bir yeniden yetkilendirmeden sonra bile başarısız olmaya devam edebilir. İlişkilenmeyi bırakın, yeniden yetkilendirin ve istemci ayarlarına dokunmadan önce bir kez deneyin. Gözlemlediğiniz bileşenlerin arkasındaki mimariyi istiyorsanız RFC 8952 okumaya değer.
Portalın kendisi yetkilendirmeyi reddederse sorun hesapta veya cihaz dağıtımındadır ve hiçbir VPN ayarı bunu düzeltmez. VPN'in çıkış ülkesini değiştirmek mekânın yerel erişim durumunu sıfırlamaz; o tablo seçtiğiniz sunucuya değil cihazınıza bağlıdır. Mekânın işletmecisine sorun ve zaman tanıyın, çünkü bakacağı şey oturum tablosudur.
Bir sonraki yolculuktan önce üç şey yazın: sıfırıncı adım olarak portal sayfası, taşıdığınız her cihaz için engellemeyi duraklatma adımı ve gerçekten test ettiğiniz bir yedek taşıma. On dakika önce çalışan bir tünel yeniden durursa bunu süresi dolmuş yetkilendirme olarak ele alın ve VPN profiline dokunmadan önce portalı yeniden denetleyin.