Wi-Fi değiştiğinde veya Ethernet takıldığında VPN’iniz neden düşer
'Yeni bir SSID, erişim noktaları arasında dolaşma ve takılı bir kablo tüneli üç ayrı yerde kırar. Kaynak adresini, ardından rotayı, ardından protokolü kontrol edin.'
İki şey tek bir arıza olarak bildirilir: dizüstü bilgisayar başka bir Wi-Fi ağına geçti, ya da Wi-Fi çalışmaya devam ederken kablo takıldı. İstemci hâlâ bağlı diyor, simge sağlıklı görünüyor ve tünel hiçbir şey taşımıyor. Altında yalnızca üç durum parçası hareket edebilir - bağlantı, yerel adres, varsayılan rota - ve hangisinin hareket ettiği tünelin kendi kendine toparlanacağını yoksa yeniden bağlanma gerektiğini belirler. Onları bu sırayla kontrol ediyorum, çünkü hesap ayarlarını değiştirmek hiçbir zaman hiçbirini düzeltmedi.
Bağlantı, adres ve rota bağımsız hareket eder
Aynı ağdaki erişim noktaları arasında dolaşma genellikle bir L2 olayıdır. Radyo yeniden ilişkilenir, arayüz adresini ve ağ geçidini korur ve tünelin bağlı olduğu hiçbir şey değişmez, bu yüzden büyük bir ofiste dolaşmak bazen fark edilmeden geçer. Başka bir SSID’ye katılmak böyle değildir: eski arayüz düşebilir, DHCP yeni bir adres, yeni bir ağ geçidi ve yeni çözümleyiciler verir ve tünelin kullandığı dış akış artık var olmaz.
Ethernet üçüncü bir biçim ekler. Wi-Fi asla düşmez, bu yüzden hiç bağlantı olayı tetiklenmez, ama kablolu arayüz kendi adresiyle görünür ve çoğu zaman metrikte varsayılan rotayı kazanır. Tünel artık tercih edilmeyen bir yolda çalışmaya devam eder ya da istemci soketini başladığı kablosuz ağa sabitler. Tarayıcıdan ikisi de aynı görünür: kablo oturduğu anda sayfalar takılır.
Yani ilk soru Wi-Fi değişti mi değil. Tünel açıkken bağlı olduğunuz adres mi, yoksa uç noktaya giden rota mı değişti.
Dış soket, az önce kaybolan bir adrese sabitlenmiş
Her tünel bir dış akıştır: sunucunun adresi ve portuyla konuşan yerel bir adres ve port. Linux’ta bu eski kaynağa bağlı bir UDP soketidir; adresi tutan arayüz kaldırıldığında gönderimler ya EADDRNOTAVAIL ile başarısız olur ya da yeni arayüzden sunucunun hiç görmediği bir kaynakla çıkar.
Uzak taraf kendi sabitlemesini tutar. MOBIKE olmayan bir IKEv2 SA adres çiftiyle tanımlanır ve bir OpenVPN oturumu öğrendiği eş adresine bağlanır ve bir NAT eşlemesi onu oluşturan özel adrese, porta ve genel adrese aittir. Başka bir NAT’ın arkasına geçin ve her yanıt artık var olmayan bir eşlemeye gider. Makinenizde hiçbir şey yanlış yapılandırılmış değil; beşli, bıraktığınız bir ağa işaret ediyor.
Kuram kurmadan önce durumu okuyun:
ss -unpher tünel soketinin gerçekte tuttuğu yerel adresi ve portu gösterir.ip route get 203.0.113.10çekirdeğin şu anda uç nokta için kullanacağı kaynak adresi ve aygıtı yazdırır.wg show wg0 endpoints,swanctl --list-sasya da istemci günlüğü uzak tarafın konuştuğunu sandığı eş adresini gösterir.
Soket adresi ile rota araması uyuşmuyorsa kopmayı buldunuz ve hiçbir kimlik bilgisi değişikliği ona dokunmaz.
Her protokol yeni bir kaynak adresle ne yapar
İstemciler değişimi farklı ölçülerde emer ve tablo, yeniden bağlanma davranışından tahmin etmek yerine istemci yapılandırmasıyla karşılaştırdığım şeydir.
| Tunnel | Recovery behaviour | Failure signature |
|---|---|---|
| WireGuard | Updates the peer endpoint when an authenticated packet arrives from a new address; no handshake needed if traffic continues. | Handshake current, no return traffic; wg show still lists the old endpoint. |
| IKEv2/IPsec | MOBIKE (RFC 4555) moves the SA to the new address; without it the responder discards packets from an unknown source. | DPD or keepalive timeouts, then a full rekey or a dead SA. |
| OpenVPN over UDP | --float accepts a packet from a new source mid-session; otherwise the session stays tied to the original peer address. | Idle until ping-restart fires, then a visible reconnect. |
| OpenVPN over TCP | The tunnel is a byte stream, so a changed source address breaks it outright. | Immediate reset and a new connection attempt. |
WireGuard’ın dolaşma kuralı yalnızca tek yönde çalışır: istemci önce yeni adresten göndermek zorundadır. Eski arayüze hâlâ bağlı bir soket bunu asla yapmaz, bu yüzden tünel canlı görünebilir ama el sıkışma zamanlayıcısı yaşlanır. protokol açıklaması uç noktanın güncellenme koşulunu tam olarak belirtir ve bir yapılandırmayı değiştirmeden önce okumaya değer.
MOBIKE pazarlık edilir, varsayılmaz. Sunucu sunmuyorsa istemci yeniden kurmak zorundadır ve bu, SA listesinden ya da günlükten doğruladığınız bir olgu, dönen bir çarktan çıkardığınız bir sonuç değildir.
Yolu rota tercihi belirler, Wi-Fi simgesi değil
İki arayüz de açıkken çekirdek metriğe ve önek uzunluğuna göre seçer. ip route show default adayları listeler ve ip route get 203.0.113.10 kaynak adres dahil gerçek kararı çözer. Metrik 100’deki kablolu varsayılan ve 600’deki kablosuz varsayılan, uç noktanın kablo oturduğu anda kaydığı anlamına gelir; önceden soket açmış her uygulama ise eski kaynağını korur.
Windows da otomatik arayüz metrikleriyle aynısını yapar, bağlantı hızından etkilenir. Get-NetRoute -DestinationPrefix 0.0.0.0/0 adayları sıralar ve Find-NetRoute -RemoteIPAddress 203.0.113.10 yığının seçeceği arayüzü ve kaynağı döndürür. Dış soketini tek bir arayüze bağlayan istemci metrik ters döndükten sonra da onu kullanmaya devam eder; bu bir bağlama kararıdır, yönlendirme arızası değil.
Android ayrımı görünür kılar: ConnectivityManager kullanılabilir ağları ve ayrı bir varsayılanı bildirir ve soketi bir Network nesnesine bağlayan VPN uygulaması yeniden bağlayana kadar bu bağı tutar. macOS’ta scutil --nwi birincil arayüzü ve sistemin kullanacağı sırayı yazdırır.
DNS, MTU ve IPv6 bağlantıyla birlikte hareket eder
Yeni bir bağlantı yeni çözümleyiciler getirir. systemd-resolved ile DNS bağlantı başınadır, resolvectl status hangi bağlantının bir ada yanıt verdiğini gösterir ve kendi çözümleyicisini dağıtan bir konuk ağı, bağlantı yeniden tercih edilene kadar tünelin ittiği DNS’yi kullanılmadan bırakabilir. Yakalayan portal durumu kötüleştirir: ilk HTTPS isteğine uç nokta yerine portal yanıt verir ve istemci ölü bir sunucu kaydeder.
Yolun MTU’su da değişir. Ethernet ve Wi-Fi genellikle 1500 bayt taşır, PPPoE 1492 ve mobil bağlantılar çoğu zaman daha az. Daha küçük MTU devralan bir tünel büyük paketlerde takılır, küçük istekler geçer ve bu yarı kırık bir bağlantı olarak okunur. ping -M do -s 1472 203.0.113.10 DF ayarlı 1500 baytlık bir paket gönderir; sessizlik yolun sandığınızdan küçük olduğu anlamına gelir.
IPv6 diğer yarıdır. Yeni bir önek dağıtan ağ, çift yığınlı istemcinin kullanacağı kaynağı değiştirir ve yalnızca v4 tünel, politika yetişene kadar v6 trafiğini dışarıda bırakır. ip -6 route show default ve ip -6 addr show yeni bağlantının hiç v6 yolu olup olmadığını yanıtlar.
Geçişi anlatmak yerine yeniden üretin
Zararsız bir istek seçin ve aynı üç komutu değişikliğin iki yanında çalıştırın: ip -br addr, ip route show default, ip route get 203.0.113.10. Sonra tünelin hâlâ paket gönderip göndermediğine bakın - tcpdump -ni any udp port 51820 WireGuard için bu, geri kalan her şey için karşılık gelen port. Eski kaynaktan çıkan paketler bir bağlama sorununa işaret eder. Yeni kaynaktan yanıtsız çıkan paketler uzak tarafı ya da aradaki NAT’ı gösterir.
İlk arızayla hangi olayın çakıştığını not edin: bağlantının düşmesi, adres değişikliği ya da varsayılan rotanın değişmesi. Bunlar farklı sorumlulara işaret eder - yeniden bağlanması gereken bir istemci, yeniden alınması gereken bir adres ya da kalıcı bir atlatma kuralına değil yapılandırma dosyasına ait bir rota.
Düzeltildi demeden önce, doğrudan trafik bloğunun boşluk boyunca hâlâ durduğunu ve adların yeni bağlantı üzerinden çözüldüğünü doğrulayın. İstemci geçişten sonra eski uç noktayı tutuyorsa önce dolaşma ya da float ayarını düzeltin. Doğru dolaşıyor ve yine yanıt almıyorsa sunucudaki eş kimliğine ve yoldaki NAT’a bakın ve sonraki kişinin karşılaştırabilmesi için iki ağ bağlamını da yazıda tutun.