VPN-oerskeakeling: as it werompaad op de âlde tunnel bliuwt

De reservetunnel komt omheech, de primêre giet del, en de applikaasje rint noch altyd yn in time-out. Op beide siden liket de tunnelstatus sûn, en dat is krekt wat it betiizjend makket. In oerskeakeling dy’t oanfragen nei de reserve ferpleatst mar de antwurden op it âlde paad lit, is gjin oerskeakeling. De hantlieding hjirûnder testet it werompaad, net allinnich de hânskodding.

Skriuw earst de rûtes oan beide einen op; in byld fan ien side kin gjin asymmetrysk paad sjen litte. It is ek de stap dy’t it meast oerslein wurdt ûnder tiiddruk.

Skriuw de rûtes fan beide siden foar de test op

Skriuw foar elk beskerme foarheaksel de primêre rûte, de reserverûte en de foarkar dy’t tusken har kiest. Nim de LAN-gateway efter elk VPN-einpunt op, want it einpunt is selden de lêste sprong.

Statyske metriken, folge rûtes en dynamysk rûteren drukke geskiktheid ferskillend út. Wês wat jo ûntwerp brûkt, en wat der nedich is om it alternatyf aktyf te meitsjen. Skriuw de betingst njonken de rûte, bygelyks in legere metryk oant de probe mislearret.

Doch dit op beide siden. In reserve dy’t oan ien kant foarkar kriget en oan de oare kant negearre wurdt, produsearret krekt de asymmetry dy’t jo besykje te foarkommen.

Folgje oanfragen en antwurden yn elke faze

Brûk in harmless tastiene applikaasje en observearje trije fazen: normaal, mislearring fan it primêre paad en werstel. Skriuw yn elke faze op hokker tunnel de oanfraach draacht en hokker it antwurd. In berikber adres fan in tsjinpartner bewiist net dat it beskerme applikaasjepaad wurket. Registrearje op beide siden sadat in ienrjochtingsstream sichtber wurdt.

As oanfragen ferpleatse en antwurden net, kontrolearje dan de rûte fan ’e fiere side nei it kliïntfoarheaksel en syn foarkar foar de reserve. Dat is in rûtearingsbeslút, gjin tunnelmislearring.

Werstel de oarspronklike betingst nei de test en befêstigje dat it primêre paad wer foarkar kriget. In wersteld primêr paad dat gjin foarkar kriget, is in oerskeakelingsûntwerp dat net ôfmakke is.

Behear de sesjestatus as de gateway feroaret

Brânmuorren en NAT kinne ferbiningstatus op ien gateway hâlde, en in paadferoaring nei in oare gateway draacht dy net oer. Guon applikaasjes meitsje sels opnij ferbining; oaren mislearje oant de sesje wersteld is. As de reserve de publike boarne of it oersette partikuliere adres feroaret, kinne regels foar tagong op ôfstân ek reagearje. Dokumintearje elke ferwachte sesjeherstart ynstee fan ûnbrutsen oerskeakeling te ûnthjitten.

Hâld stabile adressearring dêr’t de applikaasje it freget. In oerskeakelingsûntwerp dat it boarneadres foar elke sesje feroaret, is in ûntwerpkar, en it moat opskreaun wurde. Dy kar bepaalt hoefolle fan ’e ûnderbrekking brûkers echt fernimme.

Test in applikaasje dy’t in lange sesje hâldt, net allinnich in nije oanfraach.

Werstel it primêre paad en kontrolearje op flapping

Befêstigje dat rûte-oankundigingen of foarkarren rêstich wurde sûnder te ossillearjen. In flappende primêr paad kin fersteurender wêze as in dúdlike ûnderbrekking, omdat elke oergong de status weromset.

Hâld gatewaybehear berikber fia in werstelpaad, sadat de test jo sels net bûtenslút. Skriuw de fazen, de waarnommen paden en de wersteltiid op; dy registraasje is wat de folgjende oerskeakeling foarsisber makket. De oantekeningen fan strongSwan oer trochstjoeren binne nuttich as de einpunten Linux-hosts binne.