VPN sürerken yeniden bağlanıyor: radyo değişimi mi IP değişimi mi?
Kuleler arası devir teslim IP yolunu bozmayabilir. Tüneli taşıyan istemcileri onu yeniden kuranlarla karşılaştırın ve sürüşü değil ağ olayını okuyun.
Şehrin kenarını geçerken arama kesiliyor ve VPN simgesi aynı anda kayboluyor. Bunu “kule değişikliği tüneli öldürdü” diye kaydetmek cazip. İki farklı şey oldu ve bunlardan yalnızca biri kulelerle ilgili. Bir radyo devri IP adresinizi, varsayılan rotanızı ve oturumunuzu tamamen bozulmadan bırakabilir, oysa gerçek bir adres değişikliği onunla birlikte hareket edemeyen her tüneli kıracaktır. İstemcilerin o ikinci durumu nasıl ele aldığını karşılaştırmak faydalı alıştırmadır, çünkü size tasarlanmış bir davranış mı yoksa hata mı gördüğünüzü söyler.
Kule değişimi mutlaka adres değişimi değildir
Mobil ağlar, operatörün hareketlilik çapası aynı kaldığı sürece paket oturumunu devir teslimler boyunca canlı tutar. Radyo bağlantısı değişir, tünel bunu fark etmez ve hiçbir günlükte yeniden bağlanma görünmemelidir. Bu, şehir içindeki hareket için olağan durumdur.
Adresi değiştiren şey çapalar arasında geçiş, Wi-Fi'den hücresele geçiş veya uzun bir aradan sonra operatör tarafında tünelin yeniden kurulmasıdır. Bu olaylar paketlerinizin taşıdığı kaynak adresini değiştirir ve bir VPN eşi hareket etmiş bir eş görür.
Pratik sonuç, hareketin kanıt olmadığıdır. Kırk kilometre yol alan bir cihaz bütün yolda tek adres tutmuş olabilir, hareketsiz duran bir cihaz ise ağ öyle karar verdiği için adresini iki kez değiştirmiş olabilir. Olayı kaydetmek ikisini ayırmanın tek yoludur.
İki tasarım: tüneli taşı ya da yeniden kur
İstemciler, dış kaynağın değişmesini ne kadar önemsedikleri bakımından farklıdır. Bazıları tüneli üzerine kurulduğu adrese bağlar ve tam yeniden kurulum ister. Diğerleri her paketi bağımsız olarak doğrular ve yalnızca yanıtları nereye gönderdiklerini günceller.
| Mechanism | Behaviour after the source changes | What the user notices |
|---|---|---|
| WireGuard | Endpoint updated on the next authenticated packet | Usually nothing; the tunnel continues |
| IKEv2 with MOBIKE | Security association moves to the new address | Short pause, no re-authentication |
| OpenVPN over UDP with float | Peer address may change without a restart | Might survive, depending on timing |
| Client bound to one address | Session dies and is rebuilt | A visible reconnect and a new authentication |
Üst satır birçok kafa karıştırıcı raporu açıklar. WireGuard'ın kırılacak oturumu yoktur: her paket eşin dizinini taşır ve doğrulanır, bu yüzden yeni bir adresten gelen geçerli bir paket tanım gereği o eşten gelir ve kayıtlı uç nokta onu izler. Bir yolculuk boyunca sürekli “bağlı” gösteren bir istemci doğruyu söyler.
Alt satır da bir kusur değildir. Oturumu yeniden kurmak doğrulamayı geçerli adrese karşı yeniden çalıştırır; eski adres artık başkasına ait olabilecekken tam olarak istediğiniz şey budur.
Hareketi değil olayı gözlemleyin
Android'de bağlantı alt sistemi ağ değişikliklerini olay olarak bildirir ve istemcinin davranışıyla ilişkilendirmeniz gereken şeyler bunlardır. Döküm uzundur, ancak ilgili kısımlar varsayılan ağ ve onun adresidir:
adb shell dumpsys connectivity | grep -E 'NetworkAgentInfo|Default network'
adb shell ip -br addr show
adb logcat -b main -s Vpn:* | head -n 40
Sunucu tarafında dolaşım durumu için doğrudan bir ölçüm vardır. WireGuard her eş için son doğrulanan uç noktayı saklar, böylece adres değişikliği yeniden bağlanma olarak değil değişmiş bir değer olarak görünür:
sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakes
Uç noktayı yolculuktan önce ve sonra karşılaştırın. Adres ve bağlantı noktası değişmediyse tünelin hiçbir şey yapması gerekmedi ve yeniden bağlanma başka bir yerden, genellikle uygulamadan geldi. Uç nokta değiştiyse ama el sıkışma zaman damgası normal anahtar yenileme aralığına yakın kaldıysa tünel yeniden başlamak yerine taşındı.
Yeniden başlatma farklı görünür: el sıkışma zaman damgası yeniden bağlanma anına sıfırlanır ve istemci sessiz bir devam yerine bir başlatma dizisi kaydeder.
Yeniden bağlanma ne zaman doğru davranıştır
Her yeniden bağlanmayı arıza saymak, ölü oturumları canlı tutan yapılandırmalara yol açar. Adresi ağ tarafından yeniden tahsis edildiği için değişen bir eş, eski eşleme için trafik almaya devam etmemelidir ve sessizce devam eden bir istemci, simge yeşil kalırken kara deliğe gönderiyor olabilir.
İki arızayı kullanıcı açısından karşılaştırın. Yeniden bağlanma birkaç saniyeye ve yeni bir doğrulamaya mal olur. Eskimiş bir tünel ise hatasız takılan bir uygulamaya mal olur; bunu açıklamak çok daha zordur ve “internet bozuldu” diye bildirilme olasılığı çok daha yüksektir.
Altında bir politika sorusu da gizli. Bir yolu kaybetmekle diğerini kurmak arasındaki boşlukta bazı istemciler trafiği doğrudan göndermeye geri döner. Bunu önlemek otomatik kurtarmadan ayrı bir denetimdir ve bir istemci birinde iyi, diğerinde kötü olabilir. İkisinden birini ayarlamadan önce hangisine ihtiyacınız olduğuna karar verin.
Gözlenen sırayı yazın
Kullanışlı bir rapor olayın kaynağını adlandırır: yeni adresle varsayılan ağ değişikliği, Wi-Fi'den hücresele geçiş veya hiç adres değişikliği olmayan bir devir teslim. Ardından istemcinin ne yaptığını, belleğe değil sunucu tarafındaki zaman damgasına dayanarak söyler.
Tünel taşındıysa bunu söyleyin ve yeni uç nokta ailesini not edin. Yeniden kurulduysa doğrulamanın ilk denemede başarılı olup olmadığını ve boşluğun ne kadar sürdüğünü not edin. Bu üç gerçek, sağlıklı bir mobil tasarımı ağlar arasında savrulan bir istemciden ayırır.
Ve cihaz günlüğü bunu gerçekten doğrulamıyorsa “kule değişikliği” ifadesinden kaçının. Android bağlantı belgeleri kullanılabilirliği varsayılan ağ değişikliğinden ayıran geri çağrıları açıklar ve raporunuzun ihtiyaç duyduğu ayrım tam olarak budur. Geri kalan her şey sürüşle ilgili bir hikâyedir.