VPN yhdistää uudelleen ajaessa: radioverkon vaihto vai IP:n vaihto?

Puhelu katkeaa, kun ajat kaupungin reunan ohi, ja VPN-kuvake katoaa samalla hetkellä. Houkuttelee kirjata se muotoon “tukiaseman vaihto tappoi tunnelin”. Tapahtui kaksi eri asiaa, ja vain toinen niistä liittyy tukiasemiin. Radioverkon siirto voi jättää IP-osoitteesi, oletusreitin ja istunnon täysin ehjäksi, kun taas todellinen osoitteenmuutos katkaisee jokaisen tunnelin, joka ei pysty liikkumaan sen mukana. Hyödyllinen harjoitus on verrata, miten asiakkaat käsittelevät tuota toista tapausta, koska se kertoo, näetkö suunnitellun toiminnan vai virheen.

Tukiaseman vaihto ei välttämättä ole osoitteen vaihto

Matkapuhelinverkot pitävät paketti-istunnon elossa siirtojen yli niin kauan kuin operaattorin liikkuvuusankkuri pysyy samana. Radiolinkki vaihtuu, tunneli ei huomaa sitä, eikä missään lokissa pitäisi näkyä uudelleenyhdistämistä. Tämä on tavallinen tapaus kaupungin sisällä liikuttaessa.

Osoitteen vaihtaa ankkurien välinen siirto, vaihto Wi-Fistä matkapuhelinverkkoon tai operaattorin puolella tapahtuva tunnelin uudelleenperustaminen pitkän tauon jälkeen. Nuo tapahtumat korvaavat lähdeosoitteen, jota pakettisi kantavat, ja VPN-vertaiskumppani näkee siirtyneen vertaiskumppanin.

Käytännön seuraus on, että liikkuminen ei ole todiste. Laite, joka on ajanut neljäkymmentä kilometriä, on voinut pitää yhden osoitteen koko matkan, ja paikallaan oleva laite on voinut vaihtaa osoitetta kahdesti, koska verkko päätti niin. Tapahtuman tallentaminen on ainoa tapa erottaa ne toisistaan.

Kaksi mallia: siirrä tunnelia tai rakenna se uudelleen

Asiakkaat eroavat siinä, kuinka paljon ne välittävät siitä, että ulompi lähde vaihtui. Jotkut sitovat tunnelin osoitteeseen, jolle se rakennettiin, ja vaativat täydellisen uudelleenperustamisen. Toiset todentavat jokaisen paketin itsenäisesti ja vain päivittävät, mihin vastaukset lähetetään.

Ylin rivi selittää monta hämmentävää raporttia. WireGuardilla ei ole istuntoa, joka voisi katketa: jokainen paketti kantaa vertaiskumppanin indeksin ja on todennettu, joten uudesta osoitteesta saapuva kelvollinen paketti on määritelmällisesti tuolta vertaiskumppanilta, ja tallennettu päätepiste seuraa sitä. Asiakas, joka näyttää “yhdistetty” keskeytyksettä koko ajon ajan, puhuu totta.

Alin rivikään ei ole vika. Istunnon uudelleenrakentaminen suorittaa todentamisen uudelleen nykyistä osoitetta vastaan, mikä on juuri sitä, mitä haluat, kun vanha osoite voi nyt kuulua jollekin toiselle.

Tarkkaile tapahtumaa liikkumisen sijaan

Androidissa yhteyksien alijärjestelmä raportoi verkkomuutokset tapahtumina, ja juuri ne sinun pitäisi korreloida asiakkaan toiminnan kanssa. Vedos on laaja, mutta olennaiset osat ovat oletusverkko ja sen osoite:

adb shell dumpsys connectivity | grep -E 'NetworkAgentInfo|Default network'
adb shell ip -br addr show
adb logcat -b main -s Vpn:* | head -n 40

Palvelinpuolella roaming-tapaukseen on suora mittaus. WireGuard tallentaa viimeksi todennetun päätepisteen kutakin vertaiskumppania kohden, joten osoitteenmuutos näkyy muuttuneena arvona eikä uudelleenyhdistämisenä:

sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakes

Vertaa päätepistettä ennen ajoa ja sen jälkeen. Jos osoite ja portti ovat ennallaan, tunnelin ei tarvinnut tehdä mitään ja uudelleenyhdistäminen tuli muualta, yleensä sovelluksesta. Jos päätepiste muuttui mutta kättelyn aikaleima pysyi lähellä tavallista avaimenvaihtoväliä, tunneli siirtyi eikä käynnistynyt uudelleen.

Uudelleenkäynnistys näyttää erilaiselta: kättelyn aikaleima nollautuu uudelleenyhdistämisen hetkeen, ja asiakas kirjaa alustusjakson hiljaisen jatkamisen sijaan.

Milloin uudelleenyhdistäminen on oikea toimintatapa

Jokaisen uudelleenyhdistämisen pitäminen vikana johtaa kokoonpanoihin, jotka pitävät kuolleita istuntoja elossa. Vertaiskumppanin, jonka osoite vaihtui, koska verkko jakoi sen uudelleen, ei pitäisi enää vastaanottaa liikennettä vanhalle kuvaukselle, ja hiljaa jatkava asiakas voi päätyä lähettämään mustaan aukkoon kuvakkeen pysyessä vihreänä.

Vertaa kahta vikaa käyttäjän näkökulmasta. Uudelleenyhdistäminen maksaa muutaman sekunnin ja uuden todentamisen. Vanhentunut tunneli maksaa sovelluksen, joka jumiutuu ilman virhettä, mikä on paljon vaikeampaa selittää ja paljon todennäköisemmin raportoidaan muodossa “internet on rikki”.

Sen alla piilee myös periaatekysymys. Kun toinen reitti menetetään ja toista perustetaan, osa asiakkaista palaa lähettämään liikennettä suoraan. Sen estäminen on automaattisesta palautumisesta erillinen säätö, ja asiakas voi olla hyvä toisessa ja huono toisessa. Päätä, kumpaa tarvitset, ennen kuin säädät kumpaakaan.

Kirjoita havaittu järjestys muistiin

Hyödyllinen raportti nimeää tapahtuman lähteen: oletusverkon muutos uudella osoitteella, vaihto Wi-Fistä matkapuhelinverkkoon tai siirto ilman mitään osoitteenmuutosta. Sitten se kertoo, mitä asiakas teki, palvelinpuolen aikaleimalla eikä muistista.

Jos tunneli siirtyi, sano se ja merkitse uusi päätepisteperhe. Jos se perustettiin uudelleen, merkitse, onnistuiko todentaminen ensimmäisellä yrityksellä ja kuinka kauan aukko kesti. Nuo kolme seikkaa erottavat terveen mobiilisuunnittelun asiakkaasta, joka heittelehtii verkkojen välillä.

Ja vältä ilmaisua “tukiaseman vaihto”, ellet laitteen loki todella vahvista sitä. Androidin yhteyksien dokumentaatio kuvaa takaisinkutsut, jotka erottavat saatavuuden oletusverkon muutoksesta, ja juuri sitä eroa raporttisi tarvitsee. Kaikki muu on tarina ajamisesta.