VPN-failover: när returvägen blir kvar i den gamla tunneln
En reservtunnel är inte en failover förrän svaren också använder den. Registrera båda platsernas rutter, testa varje fas och bestäm vad som händer med befintliga sessioner.
Reservtunneln kommer upp, den primära går ner, och applikationen får fortfarande timeout. På båda platserna ser tunnelstatusen frisk ut, och det är just det som förvirrar. En failover som flyttar förfrågningar till reserven men lämnar svaren på den gamla vägen är inte en failover. Runbooken nedan testar returvägen, inte bara handskakningen.
Registrera först rutterna i båda ändarna; en vy från en plats kan inte visa en asymmetrisk väg. Det är också steget som oftast hoppas över under tidspress.
Registrera båda platsernas rutter före testet
För varje skyddat prefix, skriv den primära rutten, reservrutten och preferensen som väljer mellan dem. Ta med LAN-gatewayen bakom varje VPN-slutpunkt, eftersom slutpunkten sällan är det sista hoppet.
Statiska mätvärden, spårade rutter och dynamisk routing uttrycker lämplighet olika. Vet vilken din design använder, och vad som krävs för att alternativet ska bli aktivt. Skriv villkoret bredvid rutten, till exempel ett lägre mätvärde tills proben misslyckas.
Gör detta på båda platserna. En reserv som föredras på ena sidan och ignoreras på den andra producerar exakt den asymmetri du försöker undvika.
Observera förfrågningar och svar i varje fas
Använd en ofarlig tillåten applikation och observera tre faser: normal, primär vägfel och återställning. Registrera i varje fas vilken tunnel som bär förfrågan och vilken som bär svaret. En nåbar peer-adress bevisar inte att den skyddade applikationsvägen fungerar. Registrera på båda platserna så att ett enkelriktat flöde blir synligt.
Om förfrågningar flyttas men svaren inte, kontrollera den avlägsna platsens rutt till klientprefixet och dess preferens för reserven. Det är ett routingbeslut, inte ett tunnelfel.
Återställ det ursprungliga tillståndet efter testet och bekräfta att den primära vägen föredras igen. En återställd primär väg som inte föredras är en failover-design som inte är klar.
Hantera sessionstillstånd när gatewayen ändras
Brandväggar och NAT kan hålla anslutningstillstånd på en gateway, och ett vägbyte till en annan gateway flyttar inte med det. Vissa applikationer återansluter själva; andra misslyckas tills sessionen återupprättats. Om reserven ändrar den offentliga källan eller den översatta privata adressen kan även regler för fjärråtkomst reagera. Dokumentera varje förväntad sessionsomstart i stället för att lova failover utan avbrott.
Håll stabil adressering där applikationen kräver det. En failover-design som ändrar källadressen för varje session är ett designval, och det bör skrivas ned. Det valet avgör hur mycket av avbrottet användarna faktiskt märker.
Testa en applikation som håller en lång session, inte bara en ny förfrågan.
Återställ den primära vägen och kontrollera flapping
Bekräfta att ruttannonseringar eller preferenser stabiliseras utan att oscillera. En flappande primär väg kan vara mer störande än ett tydligt avbrott, eftersom varje övergång nollställer tillståndet.
Håll gatewayadministrationen nåbar via en återställningsväg, så att testet inte låser ute dig. Registrera faserna, de observerade vägarna och återställningstiden; den registreringen är det som gör nästa failover förutsägbar. strongSwans vidarebefordringsanteckningar är användbara när slutpunkterna är Linux-värdar.