Kalimi në rezervë i VPN-së: kur rruga e kthimit mbetet në tunelin e vjetër

Tuneli rezervë ngrihet, ai kryesor bie, dhe aplikacioni vazhdon të kalojë kohën e lejuar. Në të dy vendet gjendja e tunelit duket e shëndetshme, dhe pikërisht kjo ngatërron. Një kalim që i zhvendos kërkesat te rezerva por i lë përgjigjet në rrugën e vjetër nuk është kalim. Udhëzuesi më poshtë provon rrugën e kthimit, jo vetëm shtrëngimin e duarve.

Së pari regjistroni rrugët në të dy skajet; një pamje nga një vend nuk mund të tregojë një rrugë asimetrike. Është gjithashtu hapi që më shpesh anashkalohet nën presionin e kohës.

Regjistroni rrugët e të dy vendeve para provës

Për çdo parashtesë të mbrojtur, shkruani rrugën kryesore, rrugën rezervë dhe preferencën që zgjedh midis tyre. Përfshini portën LAN pas çdo pike fundore të VPN, sepse pika fundore rrallë është kërcimi i fundit.

Metrikat statike, rrugët e gjurmurta dhe rrugëtimi dinamik e shprehin përshtatshmërinë në mënyra të ndryshme. Dijeni cilën përdor dizajni juaj, dhe çfarë duhet që alternativa të bëhet aktive. Shkruani kushtin pranë rrugës, për shembull një metrikë më të ulët derisa sonda të dështojë.

Bëjeni këtë në të dy vendet. Një rezervë e preferuar nga njëra anë dhe e injoruar nga tjetra prodhon pikërisht asimetrinë që po përpiqeni të shmangni.

Vëzhgoni kërkesat dhe përgjigjet në çdo fazë

Përdorni një aplikacion të padëmshëm dhe të lejuar dhe vëzhgoni tre faza: normale, dështimin e rrugës kryesore dhe rikthimin. Në çdo fazë, regjistroni cili tunel mbart kërkesën dhe cili përgjigjen. Një adresë partneri e arritshme nuk vërteton se rruga e mbrojtur e aplikacionit funksionon. Regjistroni në të dy vendet që një rrjedhë njëdrejtimëshe të jetë e dukshme.

Nëse kërkesat lëvizin dhe përgjigjet jo, kontrolloni rrugën e vendit të largët drejt parashtesës së klientit dhe preferencën e tij për rezervën. Ky është një vendim rrugëtimi, jo një dështim tuneli.

Pas provës rikthejeni gjendjen fillestare dhe konfirmoni që rruga kryesore është përsëri e preferuar. Një rrugë kryesore e rikthyer që nuk preferohet është një dizajn kalimi i papërfunduar.

Menaxhoni gjendjen e sesionit kur ndryshon porta

Muret e zjarrit dhe NAT mund të mbajnë gjendjen e lidhjes në një portë, dhe ndryshimi i rrugës drejt një porte tjetër nuk e bart atë. Disa aplikacione rilidhen vetë; të tjerët dështojnë derisa sesioni të rivendoset. Nëse rezerva ndryshon burimin publik ose adresën private të përkthyer, edhe rregullat e aksesit në distancë mund të reagojnë. Dokumentoni çdo rinisje të pritur të sesionit në vend që të premtoni kalim pa ndërprerje.

Mbani adresim të qëndrueshëm aty ku aplikacioni e kërkon. Një dizajn kalimi që ndryshon adresën e burimit për çdo sesion është një zgjedhje dizajni, dhe duhet të shkruhet. Ajo zgjedhje përcakton sa ndërprerje vërejnë vërtet përdoruesit.

Provoni një aplikacion që mban një sesion të gjatë, jo vetëm një kërkesë të re.

Riktheni rrugën kryesore dhe kontrolloni lëkundjen

Konfirmoni që shpalljet e rrugëve ose preferencat stabilizohen pa lëkundje. Një rrugë kryesore lëkundëse mund të jetë më shqetësuese sesa një ndërprerje e qartë, sepse çdo tranzicion e rivendos gjendjen.

Mbani administrimin e portës të arritshëm përmes një rruge rikuperimi, që prova vetë të mos ju mbyllë jashtë. Regjistroni fazat, rrugët e vëzhguara dhe kohën e rikuperimit; ai regjistër është ajo që e bën kalimin e ardhshëm të parashikueshëm. Shënimet e strongSwan për përcjelljen janë të dobishme kur skajet janë hoste Linux.