Twee IPsec-gateways, geen gedeeld IP: wat failover echt doet

Dood gateway A tijdens een vergadering en kijk hoe de tunnel een minuut later via B terugkomt; de verbinding werkt, het videogesprek misschien niet. Dat is de eerlijke vorm van koude failover tussen twee IPsec-gateways met onafhankelijke adressen. De client kiest opnieuw een eindpunt en bouwt een nieuwe relatie op, wat de bereikbaarheid herstelt zonder de cryptografische toestand van de oude sessie over te dragen. De volgorde doorlopen maakt duidelijk welke beloften het ontwerp kan houden.

Zet het toneel: twee adressen, geen zwevend IP

Gateway A antwoordt op één bereikbaar adres en gateway B op een ander. De client heeft een goedgekeurde manier om B te kiezen wanneer A weg is, en er is geen gedeeld buitenadres dat beide gateways claimen. In dit ontwerp betekent een virtueel IP dat gedeelde toegangspunt, niet het interne adres dat aan een remote-accessclient wordt toegewezen.

Die definitie is belangrijk omdat de twee ideeën in tickets door elkaar lopen, en de oplossing voor de een is niet de oplossing voor de ander. Een melding dat de gedeelde ingang de gateway niet volgde, beschrijft één ontwerp. Een melding dat de laptop zijn interne adres kwijtraakte, beschrijft de lease van de client. Verschillende eigenaren, verschillende logs, verschillende reparaties.

Loop de storing door: detecteren, dan opnieuw kiezen

Eerst merkt iets dat A niet meer antwoordt. Dat kan dead-peer-detectie op de tunnellaag zijn, een routingprotocol dat een pad intrekt, of een applicatietime-out die uiteindelijk een herverbinding afdwingt. Elk heeft een andere tijdschaal, en de traagste bepaalt meestal hoe lang gebruikers wachten.

Dan kiest de client B via het mechanisme dat de uitrol ondersteunt: een tweede geconfigureerde remote, een DNS-naam die naar een gezond adres wordt omgezet, of routing die nu een ander pad verkiest. De keuze is een beleidsstap, en die moet vóór de storing bestaan, anders gebeurt het per ongeluk.

Wat B kan en niet kan erven

B kan een configuratiesjabloon, een certificaatautoriteit en een authenticatiebeleid met A delen. Het kan de levende beveiligingsassociaties niet erven. Sessiesleutels, beveiligingsparameterindexen en sequentietoestand horen bij de relatie die A en de client hebben opgebouwd, en B heeft er geen van.

Die toestand tussen gateways verplaatsen is een echt technisch probleem, daarom behandelt de strongSwan-documentatie over hoge beschikbaarheid het als een clusterontwerp en niet als een configuratievlag. Een bepaald clusterrecept is geen algemeen antwoord voor een cloudnetwerk, en het kopiëren zonder de ondersteunende infrastructuur koopt complexiteit in plaats van continuïteit.

Een nieuwe relatie opbouwen

Met B gekozen voert de client een nieuwe IKE-uitwisseling uit: nieuwe noncewaarden, nieuwe Diffie-Hellman-waarden, nieuwe identificatoren voor de resulterende associaties. Authenticatie gebeurt opnieuw bij B. Als het ontwerp op machinecredentials leunt, kan de herverbinding onbeheerd verlopen; als het een menselijke factor vereist, moet iemand aanwezig zijn om de failover te voltooien.

Definieer die gebruikerservaring vóór de storing, niet tijdens. Zeg duidelijk wat de client doet, hoe lang hij het probeert en wat hij toont als hij opgeeft, want het verschil tussen een minuut herverbinden en een supportgesprek is meestal documentatie en een getest profiel.

Hetzelfde interne adres behouden helpt applicaties die een stabiele lokale identiteit verwachten, en het behoudt hun sessies niet. NAT-bindingen verlopen, TCP-verbindingen worden gereset en alles met een eigen time-out beslist zelfstandig of het het opnieuw probeert.

Twee tunnels parallel zijn een ander ontwerp

Beide tunnels tegelijk laten draaien is een geldig patroon wanneer zowel de gateways als het routingontwerp het ondersteunen. De routeselectie kiest dan het actieve pad, en het retourpad moet overeenkomen, anders verlaat verkeer via de ene gateway en komt het via de andere terug zonder toestand om het te koppelen.

Overlappende tunnelbeleidsregels creëren op zichzelf geen ordelijke failover. Ze creëren twee kandidaten, en iets moet er deterministisch tussen beslissen, of dat nu een routingmetriek, een beleidsprioriteit of een expliciete voorkeur in de client is.

Welke vorm je ook kiest, schrijf het contract op: hoe de storing wordt gedetecteerd, hoe de alternatieve route wordt gekozen, welke authenticatie die vereist en hoe lang de herverbinding naar verwachting duurt. Een gedeeld IP kan de ontdekking vereenvoudigen, maar het is geen synoniem voor continue toestand, en beschikbaarheid is hoe dan ook een ontwerp.