Flosanta VPN-rezerva vojo ne transprenas: kontrol-listo por malsukcesa transiro
Flosantaj statikaj vojoj atendas taŭgecon, ne ke pakaĵoj haltu. Ses ordigitaj kontroloj de la pruva vojo, sojloj kaj reiro ĉe VPN-rezervo.
Via flosanta VPN-vojo estas agordita, la distanco de la rezervo estas pli granda ol tiu de la ĉefa, kaj tamen nenio iam moviĝas. Aŭ ĝi moviĝas kaj resaltas minutojn poste, dum la sendrata ligo ankoraŭ estas malsupra. En ambaŭ kazoj io alia ol la paneo, pri kiu vi zorgas, decidas la taŭgecon de la vojo.
Plenumu ĉi tiujn kontrolojn laŭorde. Ĉiu havas haltkondiĉon, kaj malsukcesan kontrolon ne povas savi la sekvaj. La ekzemploj uzas RouterOS-sintakson ĉar distanco, atingeblo de la pordego kaj rekursiva sekva salto estas ĉiuj videblaj en la agordo tie, sed la ordo validas por ĉiu enkursigilo kun spuregataj statikaj vojoj.
Nomu la paneon, kiun la rezervo devas kovri
«La ĉefa estas malsupre» estas kvar malsamaj observoj. Radio, kiu perdas sian kunulon, interfaco, kiu perdas sian portanton, malproksima pordego, kiu ĉesas respondi, kaj aplikaĵo, kiu ĉesas funkcii, ĉiuj aspektas malsame el la sidloko de la enkursigilo. Notu, por kiu el ili la dezajno estas, antaŭ ol iu ŝanĝos distancan valoron.
Poste kontrolu sendependecon. Se la ekstera transporto de la VPN iras laŭ la sama sendrata vojo aŭ laŭ alirligo, kiu dividas la saman suprenfluon, la rezervo ne estas dua panea domajno kaj estos malsupra ĝuste kiam vi bezonos ĝin. Tiru la ĉefan kablon sur papero: se la transporto de la tunelo mem mortas kun ĝi, la flosanta vojo kovras nur agordajn erarojn, ne interrompojn.
Ĉesu peti de la distanco detekti ion ajn
Pli granda distanco igas vojon malpli preferata. Tio estas la tuta tasko. Dum la ĉefa statika vojo restas taŭga, la flosanta vojo restas neaktiva, kaj tio estas ĝusta konduto, ne cimo. La paneo videblas nur kiam la ĉefa estas retirita aŭ markita kiel neatingebla.
Por statikaj vojoj tio postulas eksplicitan spurilon:
/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
Legu, kion tio testas: la sekvan salton, ne la celon. Radio, kiu ankoraŭ respondas ĉe sia loka flanko dum la plusendado preter ĝi estas rompita, tenas la ĉefan vojon aktiva. Tio estas la silenta kazo, kaj distanco plus pordega kontrolo ne kaptos ĝin. Se tiu kazo gravas, la detekto devas veni de io, kio observas la malproksiman flankon: najbareco de enkursiga protokolo, aŭ pruvo, kies vojon kaj rezultregulon vi mem difinis.
Spuru, kien iras la propraj pakaĵoj de la pruvo
Ankaŭ sanpruvo havas vojon. Post kiam datuma trafiko transiras al la VPN, senlima pruvo al la sama malproksima adreso povas sekvi ĝin, sukcesi kaj esti legata kiel pruvo, ke la ĉefa resaniĝis. Trafiko revenas al rompita vojo kaj la ciklo ripetiĝas.
Fiksu la pruvon al la vojo, kiun ĝi devas juĝi. En RouterOS la kutima maniero estas gastiganta vojo al la monitora celo tra la ĉefa pordego, kun amplekso sufiĉe malgranda, ke neniu alia vojo povas solvi ĝin, kion konstruas la rekursiva transira ekzemplo en la RouterOS-manlibro. Konfirmu ĝin en la viva tabelo kun la rezervo aktiva, ne el la agorda komento:
/ip route print detail where dst-address=203.0.113.10
# gateway should still be the primary next hop
Difinu, kion signifas pruva rezulto, antaŭ ol aldoni celojn
Unu celo, kiu rifuzas ICMP aŭ iras en prizorgon, aspektas ĝuste kiel voja paneo, kaj tri celoj sen regulo donas al vi nur tri opiniojn. Decidu la regulon unue, poste efektivigu ĝin: ekzemple, la ĉefa konsideriĝas malsupra kiam du el tri celoj malsukcesas dum du sinsekvaj intervaloj, skribite en la operacia manlibro, kie la sekva persono trovos ĝin.
Agordu paneajn kaj resaniĝajn sojlojn tiel, ke unu perdita pakaĵo ne movu la ejon. Histerezo kostas iom da detekta tempo kaj reaĉetas stabilecon. Elektu la intervalon laŭ tio, kiom longe interrompo tolereblas, ne laŭ tio, kiom rapide la pruvo povas kuri, kaj tenu la reiron pli malrapida ol la transiro, por ke la ĉefa devu pruvi sin antaŭ ol ĝi rericevos trafikon.
Kontrolu la revenan vojon kaj la sesian rakonton
Transiro, kiu funkcias nur eldirekte, estas duona dezajno. La malproksima ejo bezonas revenan vojon al via fonta gamo tra la VPN, alie la revena trafiko alvenas el neatendita adreso kaj trafas fajroŝirman staton, kiu ne plu kongruas. Ekzistantaj sesioj rompiĝos eĉ kiam novaj konektoj funkcias, do metu tion en la akceptajn kriteriojn anstataŭ promesi postvivon de la transigo.
Tenu administran aliron for de la testata vojo. Se via sola enirejo estas tra la ĉefa, transira testo ŝlosas vin ekster la aparato, kiu miskondutas.
Plenumu la akceptan sekvencon
Tri testoj kovras la plej grandan parton: fizika perdo de la ĉefa, silenta plusenda paneo kun la interfaco ankoraŭ supre, kaj restarigo de la ĉefa. Por ĉiu, registru la fonton kaj sekvan salton de la pruvo, la aktivan celan vojon, kaj freŝan permesitan aplikaĵan interŝanĝon en ambaŭ direktoj.
La silenta kazo estas tiu, kiu apartigas dezajnojn. Se la rezervo ne transprenas tie, vi konstruis ligilan monitoron anstataŭ vojan monitoron. Decidu, ĉu tio akcepteblas, kaj skribu la limigon tie, kie la deĵora inĝeniero legos ĝin. Dua konektita tunelo ne estas per si mem finita rezerva politiko.