Ş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.

MechanismBehaviour after the source changesWhat the user notices
WireGuardEndpoint updated on the next authenticated packetUsually nothing; the tunnel continues
IKEv2 with MOBIKESecurity association moves to the new addressShort pause, no re-authentication
OpenVPN over UDP with floatPeer address may change without a restartMight survive, depending on timing
Client bound to one addressSession dies and is rebuiltA 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.

İlgili makaleler