VPN atkal pieslēdzas braucot: radio šūnas maiņa vai IP maiņa?
Pāreja starp torņiem var atstāt IP ceļu neskartu. Salīdziniet klientus, kas pārvieto tuneli, ar tiem, kas to pārceļ no jauna, un lasiet tīkla notikumu, nevis braucienu.
Zvans pārtrūkst, kad braucat garām pilsētas malai, un VPN ikona pazūd tajā pašā mirklī. Kārdinoši to pierakstīt kā “torņa maiņa nogalināja tuneli”. Notika divas dažādas lietas, un tikai viena no tām ir par torņiem. Radio pāreja var atstāt jūsu IP adresi, noklusējuma maršrutu un sesiju pilnīgi neskartus, savukārt īsta adreses maiņa pārraus jebkuru tuneli, kas nevar pārvietoties līdzi. Noderīgais vingrinājums ir salīdzināt, kā klienti risina šo otro gadījumu, jo tas pasaka, vai redzat projektētu uzvedību vai kļūdu.
Torņa maiņa ne vienmēr ir adreses maiņa
Mobilie tīkli uztur pakešu sesiju dzīvu pāreju laikā, kamēr operatora mobilitātes enkurs paliek nemainīgs. Radio saite mainās, tunelis to nepamana, un nevienā žurnālā nedrīkstētu parādīties atkārtota pieslēgšanās. Tas ir parasts gadījums pārvietošanās laikā pilsētā.
Adresi maina pārvietošanās starp enkuriem, pāreja no Wi-Fi uz mobilo tīklu vai tuneļa atjaunošana operatora pusē pēc ilgas pauzes. Šie notikumi aizstāj avota adresi, ko nes jūsu paketes, un VPN partneris redz partneri, kas ir pārvietojies.
Praktiskās sekas ir tādas, ka kustība nav pierādījums. Ierīce, kas nobraukusi četrdesmit kilometrus, varēja visu ceļu saglabāt vienu adresi, un nekustīga ierīce varēja divreiz nomainīt adresi, jo tīkls tā nolēma. Notikuma reģistrēšana ir vienīgais veids, kā tos atšķirt.
Divi risinājumi: pārvietot tuneli vai pārtaisīt to
Klienti atšķiras ar to, cik ļoti viņiem rūp, ka ārējais avots ir mainījies. Daži piesaista tuneli adresei, uz kuras tas tika uzbūvēts, un pieprasa pilnīgu atjaunošanu. Citi autentificē katru paketi neatkarīgi un vienkārši atjaunina, kur sūta atbildes.
| 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 |
Augšējā rinda izskaidro daudzus mulsinošus ziņojumus. WireGuard nav sesijas, ko salauzt: katra pakete nes partnera indeksu un tiek autentificēta, tāpēc derīga pakete, kas ierodas no jaunas adreses, pēc definīcijas ir no šī partnera, un ierakstītais galapunkts tam seko. Klients, kas brauciena laikā nepārtraukti rāda “savienots”, saka patiesību.
Apakšējā rinda arī nav defekts. Sesijas pārtaisīšana atkārtoti izpilda autentifikāciju pret pašreizējo adresi, un tieši to jūs vēlaties, ja vecā adrese tagad var piederēt kādam citam.
Vērojiet notikumu, nevis kustību
Android sistēmā savienojamības apakšsistēma ziņo par tīkla izmaiņām kā notikumiem, un tieši tie jums jāsasaista ar klienta uzvedību. Izvilkums ir apjomīgs, bet būtiskās daļas ir noklusējuma tīkls un tā adrese:
adb shell dumpsys connectivity | grep -E 'NetworkAgentInfo|Default network'
adb shell ip -br addr show
adb logcat -b main -s Vpn:* | head -n 40Servera pusē ir tiešs mērījums viesabonēšanas gadījumam. WireGuard glabā pēdējo autentificēto galapunktu katram partnerim, tāpēc adreses maiņa parādās kā mainīta vērtība, nevis kā atkārtota pieslēgšanās:
sudo wg show wg0 endpoints
sudo wg show wg0 latest-handshakesSalīdziniet galapunktu pirms un pēc brauciena. Ja adrese un ports nav mainījušies, tunelim nekas nebija jādara, un atkārtotā pieslēgšanās nāca no citurienes, parasti no lietojumprogrammas. Ja galapunkts mainījās, bet rokas sasveicināšanās laika zīmogs palika tuvu parastajam atslēgas atjaunošanas intervālam, tunelis pārvietojās, nevis restartējās.
Restartēšanās izskatās citādi: rokas sasveicināšanās laika zīmogs tiek atiestatīts uz atkārtotās pieslēgšanās brīdi, un klients reģistrē inicializācijas secību, nevis klusu turpinājumu.
Kad atkārtotā pieslēgšanās ir pareizā uzvedība
Uzskatīt katru atkārtotu pieslēgšanos par kļūdu noved pie konfigurācijām, kas uztur mirušas sesijas dzīvas. Partnerim, kura adrese mainījās tāpēc, ka tīkls to pārdalīja, nevajadzētu turpināt saņemt trafiku vecajam kartējumam, un klients, kas klusi turpina, var nonākt pie sūtīšanas melnajā caurumā, kamēr ikona paliek zaļa.
Salīdziniet abas kļūmes no lietotāja skatpunkta. Atkārtota pieslēgšanās izmaksā dažas sekundes un jaunu autentifikāciju. Novecojis tunelis izmaksā lietojumprogrammu, kas karājas bez kļūdas, ko ir daudz grūtāk izskaidrot un kas daudz biežāk tiek ziņota kā “internets ir salūzis”.
Zem tā slēpjas arī politikas jautājums. Laika posmā starp viena ceļa zaudēšanu un otra izveidi daži klienti atgriežas pie trafika tiešas sūtīšanas. To novērst ir atsevišķa kontrole no automātiskās atjaunošanas, un klients var būt labs vienā un slikts otrā. Izlemiet, kas jums vajadzīgs, pirms regulējat kādu no tiem.
Pierakstiet novēroto secību
Noderīgs ziņojums nosauc notikuma avotu: noklusējuma tīkla maiņu ar jaunu adresi, pāreju no Wi-Fi uz mobilo tīklu vai pāreju bez jebkādas adreses maiņas. Pēc tam tas norāda, ko klients darīja, ar laika zīmogu no servera puses, nevis no atmiņas.
Ja tunelis pārvietojās, sakiet to un atzīmējiet jauno galapunktu saimi. Ja tas tika atjaunots, atzīmējiet, vai autentifikācija izdevās pirmajā mēģinājumā un cik ilgi pastāvēja pārtraukums. Šie trīs fakti atšķir veselīgu mobilo risinājumu no klienta, kas mētājas starp tīkliem.
Un izvairieties no frāzes “torņa maiņa”, ja vien ierīces žurnāls to tiešām neapstiprina. Android savienojamības dokumentācija apraksta atzvanus, kas atšķir pieejamību no noklusējuma tīkla maiņas, un tieši šī atšķirība ir vajadzīga jūsu ziņojumam. Viss pārējais ir stāsts par braukšanu.