VPN-transiro al rezervo: kiam la revena vojo restas en la malnova tunelo

La rezerva tunelo ekstaras, la ĉefa falas, kaj la aplikaĵo ankoraŭ finiĝas per tempolimo. Ĉe ambaŭ ejoj la stato de la tunelo aspektas sana, kaj ĝuste tio konfuzas. Transiro, kiu movas petojn al la rezervo sed lasas respondojn sur la malnova vojo, ne estas transiro. La gvidilo sube testas la revenan vojon, ne nur la manpremon.

Unue registru la itinerojn ĉe ambaŭ finaĵoj; vido el unu ejo ne povas montri nesimetrian vojon. Ĝi ankaŭ estas la paŝo plej ofte preterlasata sub tempa premo.

Registru la itinerojn de ambaŭ ejoj antaŭ la testado

Por ĉiu protektita prefikso skribu la ĉefan itineron, la rezervan itineron kaj la preferon, kiu elektas inter ili. Inkluzivu la LAN-pordegon malantaŭ ĉiu VPN-finaĵo, ĉar la finaĵo malofte estas la lasta salto.

Statikaj metrikoj, spurataj itineroj kaj dinamika enkursigo esprimas taŭgecon malsame. Sciu, kiun uzas via dezajno, kaj kion necesas por ke la alternativo fariĝu aktiva. Skribu la kondiĉon apud la itinero, ekzemple pli malaltan metrikon ĝis la provo malsukcesos.

Faru tion ĉe ambaŭ ejoj. Rezervo preferata unuflanke kaj ignorata aliflanke produktas ĝuste la nesimetrion, kiun vi provas eviti.

Observu petojn kaj respondojn en ĉiu fazo

Uzu sendanĝeran permesitan aplikaĵon kaj observu tri fazojn: normalan, fiaskon de la ĉefa vojo kaj restaŭradon. En ĉiu fazo registru, kiun tunelon portas la peton kaj kiun la respondon. Atingebla adreso de kunulo ne pruvas, ke la protektita aplika vojo funkcias. Registru ĉe ambaŭ ejoj, por ke unudirekta fluo videblu.

Se petoj moviĝas kaj respondoj ne, kontrolu la itineron de la fora ejo al la klienta prefikso kaj ĝian preferon por la rezervo. Tio estas enkursiga decido, ne tunela fiasko.

Restaŭru la originan kondiĉon post la testado kaj konfirmu, ke la ĉefa vojo denove estas preferata. Restaŭrita ĉefa vojo, kiu ne estas preferata, estas transira dezajno, kiu ne finiĝis.

Traktu sesian staton kiam la pordego ŝanĝiĝas

Fajroŝirmiloj kaj NAT povas teni konektan staton sur unu pordego, kaj voja ŝanĝo al alia pordego ne transportas ĝin. Iuj aplikaĵoj rekonektiĝas mem; aliaj fiaskas ĝis la sesio estos restarigita. Se la rezervo ŝanĝas la publikan fonton aŭ la tradukitan privatan adreson, reguloj de fora aliro ankaŭ povas reagi. Dokumentu ĉiun atendatan sesian restartigon anstataŭ promesi seninterrompan transiron.

Konservu stabilan adresadon tie, kie la aplikaĵo postulas ĝin. Transira dezajno, kiu ŝanĝas la fontan adreson por ĉiu sesio, estas dezajna elekto, kaj ĝi devus esti skribita. Tiu elekto determinas, kiom da la interrompo uzantoj efektive rimarkas.

Testu aplikaĵon, kiu tenas longan sesion, ne nur novan peton.

Restaŭru la ĉefan vojon kaj kontrolu svingadon

Konfirmu, ke anoncoj de itineroj aŭ preferoj stabiliĝas sen oscilado. Svingiĝanta ĉefa vojo povas esti pli ĝena ol klara interrompo, ĉar ĉiu transiro restarigas la staton.

Tenu la pordegan administradon atingebla per restaŭra vojo, por ke la testado mem ne ŝlosu vin ekstere. Registru la fazojn, la observitajn vojojn kaj la restaŭran tempon; tiu registro igas la sekvan transiron antaŭvidebla. La notoj de strongSwan pri plusendado estas utilaj kiam la finaĵoj estas Linux-gastigantoj.