VPN persijungia važiuojant: radijo ryšio ar IP adreso pokytis?
Perėjimas tarp bokštų gali palikti IP kelią nepaliestą. Palyginkite klientus, kurie perkelia tunelį, su tais, kurie jį atkuria, ir skaitykite tinklo įvykį, o ne kelionę.
Skambutis nutrūksta, kai pravažiuojate miesto pakraštį, ir VPN piktograma dingsta tuo pačiu metu. Gundoma tai užrašyti kaip „bokšto pakeitimas nužudė tunelį“. Įvyko du skirtingi dalykai, ir tik vienas iš jų susijęs su bokštais. Radijo perdavimas gali palikti jūsų IP adresą, numatytąjį maršrutą ir sesiją visiškai nepaliestus, o tikras adreso pakeitimas nutrauks kiekvieną tunelį, kuris negali judėti kartu su juo. Naudinga pratyba yra palyginti, kaip klientai sprendžia antrąjį atvejį, nes tai pasako, ar matote suprojektuotą elgesį, ar klaidą.
Bokšto pakeitimas nebūtinai yra adreso pakeitimas
Mobiliuosiuose tinkluose paketų sesija išlieka per perdavimus tol, kol operatoriaus mobilumo inkaras išlieka tas pats. Radijo ryšys keičiasi, tunelis to nepastebi, ir jokiame žurnale neturėtų atsirasti pakartotinio prisijungimo. Tai įprastas atvejis judant miesto viduje.
Adresą keičia perkėlimas tarp inkarų, perėjimas nuo Wi-Fi prie mobiliojo ryšio arba tunelio atkūrimas operatoriaus pusėje po ilgos pertraukos. Tie įvykiai pakeičia šaltinio adresą, kurį neša jūsų paketai, ir VPN porininkas mato porininką, kuris persikėlė.
Praktinė pasekmė ta, kad judėjimas nėra įrodymas. Įrenginys, nuvažiavęs keturiasdešimt kilometrų, galėjo visą kelią išlaikyti vieną adresą, o stovintis įrenginys galėjo du kartus pakeisti adresą, nes tinklas taip nusprendė. Įvykio užrašymas yra vienintelis būdas juos atskirti.
Du sprendimai: perkelti tunelį arba jį atkurti
Klientai skiriasi tuo, kiek jiems rūpi, kad pasikeitė išorinis šaltinis. Kai kurie pririša tunelį prie adreso, kuriuo jis buvo sukurtas, ir reikalauja visiško atkūrimo. Kiti tikrina kiekvieną paketą atskirai ir tiesiog atnaujina, kur siunčia atsakymus.
| 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 |
Viršutinė eilutė paaiškina daug painių pranešimų. WireGuard neturi sesijos, kurią būtų galima sulaužyti: kiekvienas paketas neša porininko indeksą ir yra autentifikuotas, todėl galiojantis paketas, atėjęs iš naujo adreso, pagal apibrėžimą yra iš to porininko, ir įrašytas galinis taškas jam seka. Klientas, kuris visos kelionės metu nuolat rodo „prisijungta“, sako tiesą.
Apatinė eilutė taip pat nėra defektas. Sesijos atkūrimas iš naujo vykdo autentifikavimą su dabartiniu adresu, o būtent to ir norite, kai senasis adresas dabar gali priklausyti kam nors kitam.
Stebėkite įvykį, o ne judėjimą
Android sistemoje ryšio posistemė praneša apie tinklo pokyčius kaip įvykius, ir būtent juos turėtumėte sieti su kliento elgesiu. Išrašas yra išsamus, bet svarbios dalys yra numatytasis tinklas ir jo adresas:
adb shell dumpsys connectivity | grep -E 'NetworkAgentInfo|Default network'
adb shell ip -br addr show
adb logcat -b main -s Vpn:* | head -n 40Serverio pusėje yra tiesioginis matavimas roamingo atveju. WireGuard saugo paskutinį autentifikuotą galinį tašką kiekvienam porininkui, todėl adreso pakeitimas pasirodo kaip pasikeitusi reikšmė, o ne kaip pakartotinis prisijungimas:
sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakesPalyginkite galinį tašką prieš kelionę ir po jos. Jei adresas ir prievadas nepasikeitė, tuneliui nieko nereikėjo daryti, o pakartotinis prisijungimas atėjo iš kitur, dažniausiai iš programos. Jei galinis taškas pasikeitė, o rankos paspaudimo laiko žyma liko arti įprasto raktų atnaujinimo intervalo, tunelis persikėlė, o ne persikrovė.
Persikrovimas atrodo kitaip: rankos paspaudimo laiko žyma nustatoma į pakartotinio prisijungimo momentą, o klientas įrašo inicijavimo seką, o ne tylų tęsinį.
Kada pakartotinis prisijungimas yra teisingas elgesys
Kiekvieną pakartotinį prisijungimą laikant gedimu, atsiranda konfigūracijos, kurios palaiko mirusias sesijas. Porininkas, kurio adresas pasikeitė, nes tinklas jį perskirstė, neturėtų toliau gauti srauto senajam susiejimui, o tyliai besitęsiantis klientas gali siųsti į juodąją skylę, kol piktograma lieka žalia.
Palyginkite abu gedimus iš naudotojo perspektyvos. Pakartotinis prisijungimas kainuoja kelias sekundes ir naują autentifikavimą. Pasenęs tunelis kainuoja programą, kuri užstringa be klaidos, o tai daug sunkiau paaiškinti ir daug labiau tikėtina, kad bus pranešta kaip „internetas sugedo“.
Po tuo slypi ir politikos klausimas. Tarp prarasto vieno kelio ir kito sukūrimo kai kurie klientai grįžta prie tiesioginio srauto siuntimo. To užkirtimas yra atskira kontrolė nuo automatinio atkūrimo, o klientas gali būti geras viename ir prastas kitame. Nuspręskite, ko jums reikia, prieš derindami bet kurį.
Užrašykite stebėtą seką
Naudingas pranešimas įvardija įvykio šaltinį: numatytojo tinklo pakeitimą su nauju adresu, perėjimą nuo Wi-Fi prie mobiliojo ryšio arba perdavimą visiškai be adreso pakeitimo. Tada jis nurodo, ką klientas padarė, su laiko žyma iš serverio pusės, o ne iš atminties.
Jei tunelis persikėlė, pasakykite tai ir pažymėkite naują galinių taškų šeimą. Jei jis buvo atkurtas, pažymėkite, ar autentifikavimas pavyko pirmuoju bandymu ir kiek truko tarpas. Tie trys faktai skiria sveiką mobilų sprendimą nuo kliento, kuris mėtosi tarp tinklų.
Ir venkite frazės „bokšto pakeitimas“, nebent įrenginio žurnalas tai tikrai patvirtina. Android ryšio dokumentacija aprašo atgalinius iškvietimus, kurie atskiria prieinamumą nuo numatytojo tinklo pakeitimo, ir būtent to skirtumo reikia jūsų pranešimui. Visa kita yra istorija apie vairavimą.