Drywende VPN-rugsteunroete neem nie oor nie: oorskakelingskontrolelys

Jou drywende VPN-roete is opgestel, die rugsteunafstand is groter as die primêre s'n, en niks beweeg ooit nie. Of dit beweeg, en skakel minute later terug terwyl die draadlose skakel steeds af is. In albei gevalle is dit iets anders as die fout waarvoor jy sorg wat die roete se geskiktheid bepaal.

Werk hierdie kontroles in volgorde deur. Elkeen het 'n stopvoorwaarde, en 'n mislukte kontrole kan nie deur die volgende gered word nie. Die voorbeelde gebruik RouterOS-sintaks omdat afstand, poorttoeganklikheid en rekursiewe volgende sprong almal in die konfigurasie sigbaar is, maar die volgorde geld vir enige router met gevolgde statiese roetes.

Noem die fout wat die rugsteun moet dek

“Die primêre is af” is vier verskillende waarnemings. 'n Radio wat sy eweknie verloor, 'n koppelvlak wat sy draer laat val, 'n afgeleë poort wat ophou antwoord, en 'n toepassing wat ophou werk, lyk almal anders uit die router se oogpunt. Skryf neer watter een die ontwerp vir is voordat iemand 'n afstandwaarde verander.

Kontroleer dan onafhanklikheid. As die VPN se buitenste vervoer oor dieselfde draadlose pad loop, of oor 'n toegangskakel wat dieselfde opstroom deel, is die rugsteun nie 'n tweede foutdomein nie en sal dit presies af wees wanneer jy dit nodig het. Trek die primêre kabel op papier uit: as die tonnel se eie vervoer daarmee saam sterf, dek die drywende roete net konfigurasiefoute, nie onderbrekings nie.

Hou op om afstand te vra om iets op te spoor

'n Hoër afstand maak 'n roete minder verkieslik. Dit is die hele taak. Terwyl die primêre statiese roete geskik bly, bly die drywende roete onaktief, en dit is korrekte gedrag eerder as 'n fout. Die fout word eers sigbaar wanneer die primêre onttrek of as onbereikbaar gemerk word.

Vir statiese roetes vereis dit 'n eksplisiete volger:

/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

Lees wat dit toets: die volgende sprong, nie die bestemming nie. 'n Radio wat steeds aan sy plaaslike kant antwoord terwyl dit verderaan stukkend is, hou die primêre roete aktief. Dit is die stille geval, en afstand plus 'n poortkontrole sal dit nie vang nie. As daardie geval saak maak, moet opsporing van iets kom wat die verre kant waarneem: 'n roeteringprotokol-aangrensing, of 'n peiling waarvan jy die pad en die resultaatreeks self gedefinieer het.

Volg waar die peiling se eie pakkette heengaan

'n Gesondheidspeiling het ook 'n roete. Sodra dataverkeer na die VPN skuif, kan 'n onbeperkte peiling na dieselfde afgeleë adres dit volg, slaag, en gelees word as bewys dat die primêre herstel het. Verkeer keer terug na 'n stukkende pad en die siklus herhaal hom.

Pen die peiling vas aan die pad wat dit veronderstel is om te beoordeel. In RouterOS is die gewone manier 'n gasheerroete na die moniteringsteiken deur die primêre poort, met 'n omvang klein genoeg dat geen ander roete dit kan oplos nie, wat is wat die rekursiewe oorskakelvoorbeeld in die RouterOS-handleiding bou. Bevestig dit op die lewendige tabel met die rugsteun aktief, nie uit die konfigurasiekommentaar nie:

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

Bepaal wat 'n peilingsresultaat beteken voordat teikens bygevoeg word

Een teiken wat ICMP verwerp of in instandhouding gaan, lyk presies soos 'n padfout, en drie teikens sonder 'n reël gee jou net drie menings. Bepaal eers die reël en implementeer dit dan: byvoorbeeld, die primêre tel as af wanneer twee van drie teikens vir twee opeenvolgende intervalle misluk, neergeskryf in die bestuurdersgids waar die volgende persoon dit sal kry.

Stel mislukking- en hersteldrempels sodat een verlore pakket nie die terrein verskuif nie. Histerese kos 'n bietjie opsporingstyd en koop stabiliteit terug. Kies die interval uit hoe lank 'n onderbreking verdraagsaam is, nie uit hoe vinnig die peiling kan loop nie, en hou terugskakeling stadiger as oorskakeling sodat die primêre homself moet bewys voordat dit verkeer terugkry.

Kontroleer die terugpad en die sessieverhaal

Oorskakeling wat net uitwaarts werk, is 'n halwe ontwerp. Die verre terrein het 'n roete terug na jou bronreeks oor die VPN nodig, of terugkeerverkeer kom van 'n onverwagte adres en tref firewalltoestand wat nie meer pas nie. Bestaande sessies sal breek selfs wanneer nuwe verbindings werk, so sit dit in die aanvaardingskriteria eerder as om oordragbehoud te belowe.

Hou bestuurstoegang weg van die pad wat getoets word. As jou enigste ingang deur die primêre is, sluit 'n oorskakelingtoets jou uit die toestel wat hom wangedra.

Voer die aanvaardingsreeks uit

Drie toetse dek die meeste van die grond: fisiese verlies van die primêre, 'n stille aanstuurfout met die koppelvlak steeds op, en herstel van die primêre. Teken vir elkeen die peiling se bron en volgende sprong aan, die aktiewe bestemmingsroete, en 'n vars toegelate toepassingsuitruiling in albei rigtings.

Die stille geval is die een wat ontwerpe skei. As die rugsteun daar nie oorneem nie, het jy 'n skakelmonitor gebou eerder as 'n padmonitor. Besluit of dit aanvaarbaar is, en skryf die beperking waar die diensingenieur dit sal lees. 'n Tweede gekoppelde tonnel is op sigself nie 'n voltooide rugsteunbeleid nie.