VPN loob ühenduse sõidu ajal uuesti: raadiomuutus või IP muutus?
Tornide vaheline üleandmine võib jätta IP-tee puutumata. Võrrelge kliente, kes tunnelit liigutavad, nendega, kes selle uuesti üles ehitavad, ja lugege võrgu sündmust, mitte sõitu.
Kõne katkeb, kui sõidate mööda linna servast, ja VPN-i ikoon kaob samal hetkel. Kiusatus on kirjutada see „tornivahetus tappis tunneli“ alla. Juhtus kaks erinevat asja ja ainult üks neist puudutab torne. Raadioüleandmine võib jätta teie IP-aadressi, vaikimisi marsruudi ja sessiooni täiesti puutumata, samas kui tegelik aadressimuutus katkestab iga tunneli, mis ei suuda sellega kaasa liikuda. Kasulik harjutus on võrrelda, kuidas kliendid seda teist juhtumit käsitlevad, sest see ütleb teile, kas näete kavandatud käitumist või viga.
Tornivahetus ei ole tingimata aadressimuutus
Mobiilivõrgud hoiavad paketisessiooni üleandmiste ajal elus seni, kuni operaatori mobiilsuse ankur jääb samaks. Raadiolüli muutub, tunnel ei märka seda ja üheski logis ei tohiks taastühendust ilmuda. See on tavaline juhtum linnas liikumisel.
Aadressi muudab ankrute vaheline liikumine, üleminek Wi-Fi-lt mobiilivõrgule või operaatori poolel toimuva tunneli taastamine pärast pikka pausi. Need sündmused asendavad lähteaadressi, mida teie paketid kannavad, ja VPN-i partner näeb partnerit, mis on liikunud.
Praktiline järeldus on, et liikumine ei ole tõend. Seade, mis on läbinud nelikümmend kilomeetrit, võis kogu tee hoida üht aadressi, ja paigal seisev seade võis aadressi kaks korda vahetada, sest võrk otsustas nii. Sündmuse salvestamine on ainus viis neid eristada.
Kaks lahendust: liiguta tunnelit või ehita see uuesti
Kliendid erinevad selle poolest, kui palju neid häirib, et välimine lähtekoht muutus. Mõned seovad tunneli aadressiga, millele see ehitati, ja nõuavad täielikku taastamist. Teised autendivad iga paketti eraldi ja lihtsalt uuendavad, kuhu vastused saata.
| 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 |
Ülemine rida selgitab paljusid segaseid aruandeid. WireGuardil ei ole sessiooni, mida katkestada: iga pakett kannab partneri indeksit ja on autenditud, seega uuelt aadressilt saabuv kehtiv pakett on definitsiooni järgi sellelt partnerilt ja salvestatud lõpp-punkt järgib seda. Klient, mis näitab sõidu vältel pidevalt „ühendatud“, räägib tõtt.
Alumine rida ei ole samuti viga. Sessiooni uuesti ülesehitamine käivitab autentimise uuesti praeguse aadressi vastu, mis on täpselt see, mida soovite, kui vana aadress võib nüüd kuuluda kellelegi teisele.
Jälgige sündmust, mitte liikumist
Androidis teatab ühenduvuse alamsüsteem võrgu muutustest sündmustena ja just neid peaksite kliendi käitumisega korreleerima. Väljavõte on mahukas, kuid olulised osad on vaikevõrk ja selle aadress:
adb shell dumpsys connectivity | grep -E 'NetworkAgentInfo|Default network'
adb shell ip -br addr show
adb logcat -b main -s Vpn:* | head -n 40Serveri poolel on rändluse juhtumi jaoks otsene mõõtmine. WireGuard salvestab iga partneri kohta viimase autenditud lõpp-punkti, seega aadressimuutus ilmub muutunud väärtusena, mitte taastühendusena:
sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakesVõrrelge lõpp-punkti enne ja pärast sõitu. Kui aadress ja port on muutumatud, ei pidanud tunnel midagi tegema ja taastühendus tuli mujalt, tavaliselt rakendusest. Kui lõpp-punkt muutus, kuid käepigistuse ajatempel jäi oma tavapärase võtmeuuenduse intervalli lähedale, liikus tunnel, mitte ei taaskäivitunud.
Taaskäivitamine näeb teistsugune välja: käepigistuse ajatempel nullitakse taastühenduse hetkele ja klient logib initsialiseerimisjärjestuse, mitte vaikse jätkumise.
Millal on taastühendus õige käitumine
Iga taastühenduse pidamine veaks viib konfiguratsioonideni, mis hoiavad surnud sessioone elus. Partner, mille aadress muutus, sest võrk määras selle ümber, ei tohiks enam vana vastenduse jaoks liiklust saada, ja vaikselt jätkav klient võib saata musta auku, samal ajal kui ikoon jääb roheliseks.
Võrrelge kahte tõrget kasutaja vaatepunktist. Taastühendus maksab paar sekundit ja uue autentimise. Aegunud tunnel maksab rakenduse, mis jääb veata rippuma, mida on palju raskem selgitada ja mis teatatakse palju tõenäolisemalt kui „internet on katki“.
Selle all peitub ka poliitikaküsimus. Vahemikus ühe tee kaotamise ja teise loomise vahel lülituvad mõned kliendid tagasi liikluse otse saatmisele. Selle vältimine on automaatsest taastamisest eraldi juhtimine ja klient võib olla ühes hea ning teises halb. Otsustage, millist vajate, enne kui kumbagi häälestate.
Kirjutage vaadeldud järjestus üles
Kasulik aruanne nimetab sündmuse allika: vaikevõrgu muutus uue aadressiga, üleminek Wi-Fi-lt mobiilivõrgule või üleandmine ilma igasuguse aadressimuutuseta. Seejärel märgib see, mida klient tegi, serveripoole ajatempliga, mitte mälust.
Kui tunnel liikus, öelge seda ja märkige uus lõpp-punkti perekond. Kui see taastati, märkige, kas autentimine õnnestus esimesel katsel ja kui kaua vahemik kestis. Need kolm fakti eristavad tervet mobiilikavandit kliendist, mis võrkude vahel edasi-tagasi viskub.
Ja vältige väljendit „tornivahetus“, kui seadme logi seda tõesti ei tõesta. Androidi ühenduvuse dokumentatsioon kirjeldab tagasikutseid, mis eristavad kättesaadavust vaikevõrgu muutusest, ja just seda eristust teie aruanne vajab. Kõik muu on lugu sõitmisest.