VPN pārslēgšanās: kad atpakaļceļš paliek vecajā tunelī

Rezerves tunelis paceļas, galvenais nokrīt, un lietotne joprojām pārsniedz laika limitu. Abās vietās tuneļa statuss izskatās vesels, un tieši tas maldina. Pārslēgšanās, kas pārvieto pieprasījumus uz rezervi, bet atstāj atbildes vecajā ceļā, nav pārslēgšanās. Tālāk esošā instrukcija pārbauda atpakaļceļu, ne tikai roku sasveicināšanos.

Vispirms pierakstiet maršrutus abos galos; vienas vietas skats nevar parādīt asimetrisku ceļu. Tas ir arī solis, ko laika spiedienā izlaiž visbiežāk.

Pirms testa pierakstiet abu vietu maršrutus

Katram aizsargātajam prefiksam pierakstiet galveno maršrutu, rezerves maršrutu un prioritāti, kas izvēlas starp tiem. Iekļaujiet LAN vārteju aiz katra VPN galapunkta, jo galapunkts reti ir pēdējais lēciens.

Statiskās metrikas, izsekotie maršruti un dinamiskā maršrutēšana piemērotību izsaka atšķirīgi. Ziniet, kuru izmanto jūsu dizains, un kas nepieciešams, lai alternatīva kļūtu aktīva. Pierakstiet nosacījumu maršruta malā, piemēram, zemāku metriku, līdz pārbaude neizdodas.

Dariet to abās vietās. Rezerve, kurai dod priekšroku vienā pusē un kuru ignorē otrā, rada tieši to asimetriju, no kuras cenšaties izvairīties.

Vērojiet pieprasījumus un atbildes katrā fāzē

Izmantojiet nekaitīgu atļautu lietotni un vērojiet trīs fāzes: normālu, galvenā ceļa atteici un atjaunošanu. Katrā fāzē pierakstiet, kurš tunelis nes pieprasījumu un kurš atbildi. Sasniedzama partnera adrese nepierāda, ka aizsargātais lietotnes ceļš darbojas. Fiksējiet abās vietās, lai vienvirziena plūsma būtu redzama.

Ja pieprasījumi pārvietojas, bet atbildes ne, pārbaudiet tālās vietas maršrutu uz klienta prefiksu un tā prioritāti rezervei. Tas ir maršrutēšanas lēmums, nevis tuneļa atteice.

Pēc testa atjaunojiet sākotnējo stāvokli un apstipriniet, ka galvenajam ceļam atkal ir priekšroka. Atjaunots galvenais ceļš, kuram nav priekšrokas, ir nepabeigts pārslēgšanās dizains.

Pārvaldiet sesijas stāvokli, kad mainās vārteja

Ugunsmūri un NAT var turēt savienojuma stāvokli vienā vārtejā, un ceļa maiņa uz citu vārteju to nepārnes. Dažas lietotnes pašas pieslēdzas atkārtoti; citas neizdodas, līdz sesija tiek atjaunota. Ja rezerve maina publisko avotu vai tulkoto privāto adresi, arī attālinātās piekļuves noteikumi var reaģēt. Dokumentējiet jebkuru gaidāmo sesijas restartu, nevis soliet pārslēgšanos bez pārtraukuma.

Saglabājiet stabilu adresāciju tur, kur lietotne to prasa. Pārslēgšanās dizains, kas maina avota adresi katrai sesijai, ir dizaina izvēle, un tas jāpieraksta. Šī izvēle nosaka, cik lielu pārtraukumu lietotāji faktiski pamana.

Testējiet lietotni, kas notur garu sesiju, ne tikai jaunu pieprasījumu.

Atjaunojiet galveno ceļu un pārbaudiet mirgošanu

Apstipriniet, ka maršrutu paziņojumi vai prioritātes nostabilizējas bez svārstībām. Mirgojošs galvenais ceļš var būt traucējošāks par skaidru atteici, jo katra pāreja atiestata stāvokli.

Turiet vārtejas administrēšanu sasniedzamu pa atjaunošanas ceļu, lai tests pats jūs neizslēgtu. Pierakstiet fāzes, novērotos ceļus un atjaunošanas laiku; tieši šis ieraksts padara nākamo pārslēgšanos paredzamu. strongSwan piezīmes par pāradresāciju ir noderīgas, kad galapunkti ir Linux resursdatori.