Kiel MOBIKE tenas IKEv2 VPN vivanta kiam la reto ŝanĝiĝas

Telefono forlasas Wi-Fi kaj aliĝas al la ĉela reto, tekkomputilo transiras de Ethernet al konekta punkto, kaj la IKEv2-tunelo aŭ supervivas aŭ ne. MOBIKE estas la etendo, kiu ebligas ĝin supervivi, informante la malproksiman flankon ke la fonta adreso ŝanĝiĝis anstataŭ rekomenci de nulo. Kion ĝi ne faras, estas teni ĉiun aplikaĵon vivanta dum la ŝanĝo. Tio estas du asertoj, kaj la dua estas tio, kion homoj kutime celas.

Trairu la transiron laŭ etapoj, ĉar ĉiu etapo malsukcesas malsame.

Kion la ĝisdatigo efektive ŝanĝas

Dum la sekureca asocio ankoraŭ validas, la iniciatanto lernas sian novan adreson kaj sendas ĝisdatigon al la respondanto, kiu tiam uzas tiun adreson por la sama asocio. La sekurecaj parametroj ne estas renegocitaj denove de nulo. Tio estas la tuta avantaĝo: neniu nova aŭtentikiga raŭndo, neniu nova ŝlosila interŝanĝo, neniu peto al la uzanto. Ĝi ankaŭ signifas, ke la superviva stato ankoraŭ apartenas al la malnova seanco.

MOBIKE povas ankaŭ movi trafikon al UDP-kaplinĉado, kaj tial funkcianta tunelo foje ekuzas pordon 4500 post retoŝanĝo. Tiu transiro per si mem ne pruvas ke NAT estis detektita, kvankam la du ofte aperas kune.

Ĉu via profilo efektive ebligas ĝin

Ambaŭ flankoj devas subteni la etendon, kaj la deplojo devas ebligi ĝin. En strongSwan la konduto estas agordebla por ĉiu konekto, kaj interfacaj aŭ vojoŝanĝoj povas ekigi vojo-serĉon kaj ĝisdatigon kiam necese. Inspektu la aktualajn agordojn de la konekto anstataŭ supozi ke ĉiu IKEv2-profilo ebligas ĝin. Profilo kopiita el gvidilo pli malnova ol la funkcio estas ofta kaŭzo de ĉi tio.

La negocita stato en ambaŭ flankoj estas la aŭtoritato, ne la dokumentaro por la produkta familio.

Trairu la transiron laŭ etapoj

Registru la staton de la aplikaĵo antaŭ ol movi retojn. Poste movu, kaj registru la staton de la kliento kaj de la servilo poste. Mankanta adreso, malkontaktebla samtavolo kaj aplikaĵo kiu devas rekonekti sian propran seancon estas tri malsamaj rezultoj. Nur la unuaj du apartenas al la VPN-tavolo; la tria apartenas al kiu ajn protokolo kiun la aplikaĵo parolas.

Komparu retoŝanĝon kun senmova testado, por ke vi sciu kiu evento kaŭzas la problemon. Trakapacita mezuro en la fina reto ne povas reprodukti transiron. Ĝi mezuras la celon, ne la vojaĝon.

Apartigu la malsukcesajn tavolojn

Longdaŭra TCP-seanco povas malsukcesi pro kialoj ekster la IKEv2-interŝanĝo. La nova reto povas filtri, solvi aŭ enkursigi malsame. La tunela adreso eble ne ŝanĝiĝos entute dum la vojo sub ĝi ŝanĝiĝas. Tial rekonekto de la aplikaĵo povas ripari ion kion la VPN neniam rompis.

Tenu la blokadan politikon en loko ankaŭ dum vi rekuperas.

Aŭtomata moviĝemo kaj regulo malhelpanta rektan trafikon estas malsamaj regiloj, kaj malŝalti la duan por ke la unua funkciu estas malbona interŝanĝo. Se la moviĝema ĝisdatigo malsukcesas, la blokado estu tenata anstataŭ lasi trafikon ĉirkaŭ la tunelo.

Kion registri kiam ĝi ripetiĝas

Konservu tempomarkojn kaj ambaŭ adresojn de ambaŭ flankoj. Tiu registro montras ĉu la ĝisdatigo finiĝis antaŭ ol la aplikaĵo perdis kontakton, kio estas la diferenco inter moviĝema fuŝo kaj aplikaĵa tempolimo. Poste komparu la ŝanĝodirekton: forlasi Wi-Fi por la ĉela reto ne estas simetra kun la malo. Unu direkto povas funkcii dum la alia malsukcesas.

Tiu nesimetrio estas sufiĉe ofta por esti la unua afero testenda.

Kun la registro en la mano, la incidento ĉesas esti ankoraŭ alia malkonektita piktogramo kaj fariĝas unu evento en sinsekvo kun konata posedanto. Kaj tio estas ĉio, kion trairo povas honeste promesi.