Driuwende VPN-backup-route nimt net oer: failover-kontrolelist

Driuwende statyske routes wachtsje op geskiktheid, net op pakketten dy't stopje. Seis oardere kontrôles foar probepaard, drompels en weromfal op in VPN-backup.

Jo driuwende VPN-route is konfigurearre, de backup-ôfstân is grutter as dy fan 'e primêre, en dochs beweecht neat ea. Of it beweecht, en springt minuten letter werom wylst de draadloze keppeling noch del is. Yn beide gefallen beslút wat oars as de storing dêr't jo jo soargen oer meitsje oer de geskiktheid fan 'e route.

Wurkje dizze kontrôles yn oarder ôf. Elk hat in stopbetingst, en in mislearre kontrôle kin net troch de folgjende rêden wurde. De foarbylden brûke RouterOS-syntaksis om't ôfstân, berikberens fan 'e gateway en rekursive folgjende hop dêr allegear sichtber binne yn 'e konfiguraasje, mar de oarder jildt foar elke router mei folge statyske routes.

Neam de storing dy't de backup dekke moat

«De primêre is del» binne fjouwer ferskillende waarnimmings. In radio dy't syn pear ferliest, in interface dy't syn drager ferliest, in fiere gateway dy't ophâldt mei antwurdzjen, en in applikaasje dy't ophâldt mei wurkjen sjogge der allegear oars út fan 'e router syn plak. Skriuw op foar hokker fan dizze it ûntwerp is foardat immen in ôfstânwearde feroaret.

Kontrolearje dan ûnôfhinklikens. As it bûtenste ferfier fan 'e VPN oer itselde draadloze paad rint, of oer in tagongskeppeling dy't deselde upstream dielt, is de backup gjin twadde flaterdomein en sil krekt del wêze as jo him nedich hawwe. Lûk de primêre kabel op papier út: as it ferfier fan 'e tunnel sels dermei stjert, dekt de driuwende route allinnich konfiguraasjeflaters, gjin ûnderbrekkings.

Hâld op mei fan 'e ôfstân te freegjen om wat te detektearjen

In hegere ôfstân makket in route minder foarkommend. Dat is it hiele wurk. Wylst de primêre statyske route geskikt bliuwt, bliuwt de driuwende route ynaktyf, en dat is korrekt gedrach yn plak fan in bug. De storing wurdt pas sichtber as de primêre weromlutsen of as ûnberikber markearre wurdt.

Foar statyske routes freget dat om in eksplisite tracker:

/ip route
add dst-address=10.20.0.0/24 gateway=192.0.2.1 distance=1 check-gateway=ping
add dst-address=10.20.0.0/24 gateway=wg-backup distance=10

Lês wat dat test: de folgjende hop, net de bestemming. In radio dy't noch antwurdet oan syn lokale kant wylst it trochstjoeren derfoarby brutsen is, hâldt de primêre route aktyf. Dat is it stille gefal, en ôfstân plus in gateway-kontrôle sil it net fange. As dat gefal fan belang is, moat de deteksje komme fan wat de fiere kant waarnimt: in neistlizzens fan in routingprotokol, of in probe wêrfan jo it paad en de resultaatregel sels definiearre hawwe.

Folgje wêr't de eigen pakketten fan 'e probe hinne geane

In sûnensprobe hat ek in route. Sadree't dataferkear nei de VPN ferhuzet, kin in ûnbeheinde probe nei itselde fiere adres it folgje, slagje, en lêzen wurde as bewiis dat de primêre weromkaam. Ferkear giet werom nei in brutsen paad en de syklus werhellet him.

Pin de probe oan it paad dat er beoardielje moat. Yn RouterOS is de gewoane manier in host-route nei it monitoringsdoel fia de primêre gateway, mei in berik lyts genôch dat gjin oare route it oplosse kin, wat is wat it rekursive failover-foarbyld yn 'e RouterOS-hânlieding bout. Befêstigje it op 'e libbene tabel mei de backup aktyf, net út it konfiguraasjekommentaar:

/ip route print detail where dst-address=203.0.113.10
# gateway should still be the primary next hop

Bepaal wat in proberesultaat betsjut foardat jo doelen tafoegje

Ien doel dat ICMP wegere of yn ûnderhâld giet liket krekt op in paadflat, en trije doelen sûnder regel jouwe jo mar trije mieningen. Bepaal earst de regel en fiere dy dan út: bygelyks, de primêre jildt as del as twa fan trije doelen mislearje yn twa opfolgjende yntervallen, opskreaun yn 'e behearhânlieding dêr't de folgjende persoan it fine sil.

Set flaters- en werstelldrompels sa dat ien ferlern pakket de lokaasje net ferpleatst. Hysterese kostet in bytsje deteksjetiid en keapet stabiliteit werom. Kies it ynterval út hoe lang't in ûnderbrekking te fernearen is, net út hoe fluch as de probe rinne kin, en hâld it weromfallen stadiger as it failover sadat de primêre himsels bewisse moat foardat er ferkear weromkriget.

Kontrolearje it werompaad en it ferhaal fan 'e sesjes

Failover dat allinnich útgeand wurket is in heal ûntwerp. It fiere plak hat in route werom nei jo boarneberik oer de VPN nedich, oars komt weromferkear fan in ûnferwacht adres en rekket it firewallsteat dy't net mear oerienkomt. Besteande sesjes sille brekke sels as nije ferbiningen wurkje, dus set dat yn 'e akseptkriteria yn plak fan te beloofjen dat de oerdracht oerlibbet.

Hâld beheartagong bûten it paad dat test wurdt. As jo iennichste yngong fia de primêre is, slút in failover-test jo bûten it apparaat dat him ferkeard gedraacht.

Fier de akseptsekwinsje út

Trije tests dekke it measte: fysyk ferlies fan 'e primêre, in stille trochstjoerflat mei de interface noch omheech, en werstel fan 'e primêre. Registrearje foar elk de boarne en folgjende hop fan 'e probe, de aktive bestemmingsroute, en in farsk tastien applikaasje-útwikseling yn beide rjochtingen.

It stille gefal is dejinge dy't ûntwerpen skiedt. As de backup dêr net oernimt, hawwe jo in keppelingmonitor boud yn stee fan in paadmonitor. Bepaal oft dat akseptabel is, en skriuw de beheining dêr't de tsjinstingineur it lêze sil. In twadde ferbûn tunnel is op himsels gjin foltôge backupbelied.

Relatearre artikelen