Comutare de rezervă VPN: când calea de întoarcere rămâne pe tunelul vechi

Tunelul de rezervă urcă, tunelul principal cade, iar aplicația încă depășește timpul limită. În ambele site-uri starea tunelului pare sănătoasă, și exact asta încurcă. O comutare care mută cererile pe rezervă dar lasă răspunsurile pe calea veche nu este o comutare. Ghidul de mai jos testează calea de întoarcere, nu doar strângerea de mână.

Înregistrați mai întâi rutele la ambele capete; o vedere dintr-un singur site nu poate arăta o cale asimetrică. Este și pasul cel mai des omis sub presiunea timpului.

Înregistrați rutele ambelor site-uri înainte de test

Pentru fiecare prefix protejat, scrieți ruta principală, ruta de rezervă și preferința care alege între ele. Includeți gateway-ul LAN din spatele fiecărui endpoint VPN, pentru că endpoint-ul este rareori ultimul salt.

Metricile statice, rutele urmărite și rutarea dinamică exprimă eligibilitatea diferit. Știți pe care o folosește designul dvs. și ce este nevoie pentru ca alternativa să devină activă. Scrieți condiția lângă rută, de exemplu o metrică mai mică până când sonda eșuează.

Faceți acest lucru în ambele site-uri. O rezervă preferată pe o parte și ignorată pe cealaltă produce exact asimetria pe care încercați să o evitați.

Observați cererile și răspunsurile în fiecare fază

Folosiți o aplicație permisă și inofensivă și observați trei faze: normală, defectarea căii principale și restaurarea. În fiecare fază, înregistrați care tunel duce cererea și care duce răspunsul. O adresă de partener accesibilă nu dovedește că calea protejată a aplicației funcționează. Înregistrați în ambele site-uri ca un flux unidirecțional să fie vizibil.

Dacă cererile se mută și răspunsurile nu, verificați ruta site-ului îndepărtat către prefixul clientului și preferința lui pentru rezervă. Aceasta este o decizie de rutare, nu o defecțiune a tunelului.

Restabiliți condiția inițială după test și confirmați că principalul este din nou preferat. Un principal restaurat care nu este preferat este un design de comutare neterminat.

Gestionați starea sesiunii când se schimbă gateway-ul

Firewall-urile și NAT pot păstra starea conexiunii pe un gateway, iar o schimbare de cale către alt gateway nu o transportă. Unele aplicații se reconectează singure; altele eșuează până când sesiunea este restabilită. Dacă rezerva schimbă sursa publică sau adresa privată tradusă, și regulile de acces la distanță pot reacționa. Documentați orice repornire de sesiune așteptată în loc să promiteți comutare fără întrerupere.

Mențineți adresarea stabilă acolo unde aplicația o cere. Un design de comutare care schimbă adresa sursă la fiecare sesiune este o alegere de design și ar trebui scrisă. Acea alegere determină cât de mult din întrerupere observă utilizatorii.

Testați o aplicație care ține o sesiune lungă, nu doar o cerere nouă.

Restabiliți principalul și verificați oscilația

Confirmați că anunțurile de rută sau preferințele se stabilizează fără oscilație. Un principal oscilant poate fi mai perturbator decât o cădere clară, pentru că fiecare tranziție resetează starea.

Păstrați administrarea gateway-ului accesibilă printr-o cale de recuperare, ca testul să nu vă blocheze afară. Înregistrați fazele, căile observate și timpul de recuperare; acea înregistrare este ce face următoarea comutare previzibilă. notele strongSwan despre forwardare sunt utile când capetele sunt gazde Linux.