Preklop VPN: ko povratna pot ostane v starem tunelu
Rezervni tunel ni preklop, dokler ga ne uporabijo tudi odgovori. Zapišite poti obeh lokacij, preizkusite vsako fazo in odločite, kaj se zgodi z obstoječimi sejami.
Rezervni tunel se dvigne, primarni pade, aplikacija pa še vedno preseže časovno omejitev. Na obeh lokacijah je stanje tunela videti zdravo, in prav to zmede. Preklop, ki premakne zahteve na rezervo, a odgovore pusti na stari poti, ni preklop. Spodnje navodilo preizkusi povratno pot, ne le rokovanja.
Najprej zapišite poti na obeh koncih; pogled z ene lokacije ne more pokazati asimetrične poti. To je tudi korak, ki se pod časovnim pritiskom najpogosteje izpusti.
Pred preizkusom zapišite poti obeh lokacij
Za vsako zaščiteno predpono zapišite primarno pot, rezervno pot in prednost, ki izbira med njima. Vključite prehod LAN za vsako končno točko VPN, ker je končna točka redko zadnji skok.
Statične metrike, sledene poti in dinamično usmerjanje izražajo primernost različno. Vedite, katero uporablja vaš načrt, in kaj je potrebno, da alternativa postane aktivna. Zapišite pogoj ob poti, na primer nižjo metriko, dokler preizkus ne spodleti.
Naredite to na obeh lokacijah. Rezerva, ki je prednostna na eni strani in prezrta na drugi, ustvari natanko tisto asimetrijo, ki se ji poskušate izogniti.
Opazujte zahteve in odgovore v vsaki fazi
Uporabite neškodljivo dovoljeno aplikacijo in opazujte tri faze: običajno, odpoved primarne poti in obnovitev. V vsaki fazi zapišite, kateri tunel nosi zahtevo in kateri odgovor. Dosegljiv naslov partnerja ne dokazuje, da zaščitena pot aplikacije deluje. Zabeležite na obeh lokacijah, da bo enosmerni tok viden.
Če se zahteve premaknejo, odgovori pa ne, preverite pot oddaljene lokacije do predpone odjemalca in njeno prednost za rezervo. To je odločitev o usmerjanju, ne odpoved tunela.
Po preizkusu obnovite prvotno stanje in potrdite, da je primarna pot spet prednostna. Obnovljena primarna pot, ki ni prednostna, je nedokončan načrt preklopa.
Upravljajte stanje seje ob spremembi prehoda
Požarni zidovi in NAT lahko hranijo stanje povezave na enem prehodu, sprememba poti na drug prehod pa ga ne prenese. Nekatere aplikacije se povežejo same; druge odpovejo, dokler seja ni obnovljena. Če rezerva spremeni javni vir ali prevedeni zasebni naslov, se lahko odzovejo tudi pravila oddaljenega dostopa. Dokumentirajte vsak pričakovan ponovni zagon seje, namesto da bi obljubljali preklop brez prekinitve.
Ohranite stabilno naslavljanje tam, kjer ga aplikacija zahteva. Načrt preklopa, ki spremeni izvorni naslov za vsako sejo, je oblikovalska izbira in jo je treba zapisati. Ta izbira določa, koliko prekinitve uporabniki v resnici opazijo.
Preizkusite aplikacijo, ki drži dolgo sejo, ne le nove zahteve.
Obnovite primarno pot in preverite utripanje
Potrdite, da se oznanila poti ali prednosti ustalijo brez nihanja. Utripajoča primarna pot je lahko bolj moteča kot jasna odpoved, ker vsak prehod ponastavi stanje.
Ohranite upravljanje prehoda dosegljivo po poti za obnovitev, da vas preizkus sam ne zaklene. Zapišite faze, opazovane poti in čas obnovitve; prav ta zapis naredi naslednji preklop predvidljiv. Opombe strongSwan o posredovanju so uporabne, ko so končne točke gostitelji Linux.