Två aktiva IPsec-tunnlar behöver fortfarande en plan för returvägen

Öppna en terminal på en arbetsstation på ena platsen och anslut till en server på den andra. Det enda TCP-samtalet måste nu passera fyra gateways i stället för två, och det intressanta är inte om det fungerar en bra dag. Det intressanta är vilket gateway-par vägen ut valde, vilket par svaret väljer, och vem som håller tillståndet för flödet medan det händer. Ingenting i routingtabellen avgör det åt dig.

Rita fyra gateways innan du ritar en rutt

En dubbelaktiv design med två oberoende VPN-brandväggar per plats, ett par per leverantör, ger dig två användbara vägar och tre sätt att bryta dem. Skriv ned adresserna innan du konfigurerar något: klienten som den syns före och efter varje gateway, servern likaså, nästa hopp ut och nästa hopp tillbaka.

Den tabellen är designen. Allt efter den är en fråga om enheterna håller med tabellen.

Hur vägen ut väljs

Ett multipath-routinglager med lika kostnad fördelar flöden över nästa hopp genom att hasha huvudfält, vilket RFC 2992 beskriver i detalj. Det valet kan vara helt tillståndslöst: det behöver ingen post för anslutningsspårning, bara en stabil hash över oförändrade fält. Håll vägmängden och hash-indata konstanta och varje paket i flödet väljer samma nästa hopp.

Val per flöde undviker den omordning som paket-för-paket-balansering skulle orsaka på länkar med olika fördröjning. Det lovar inte att lika routingkostnad betyder lika uppmätt latens, för det gör det inte. Och när vägarnas sammansättning ändras remappas flöden, så att anslutningen överlever under ett fel är ett eget krav från vägval.

Vad returvägen faktiskt behöver

Här slutar genomgången att vara symmetrisk. En stabil hash utåt säger ingenting om vad den avlägsna platsen gör med svaret. Om en oberoende brandvägg måste se båda riktningarna av anslutningen för att hålla användbart tillstånd, lämnar en returväg som går förbi den trafik som inte matchar någonting alls. Två lådor med liknande regeluppsättningar är inte delat tillstånd.

Bekräfta det implementerade tvåvägsbeteendet, eller skriv en uttrycklig policy som håller de nödvändiga gränserna sammanhängande. En gissning här upptäcks under ett avbrott, av människor som inte njuter av det.

Där översättningen bestämmer åt dig

NAT är den andra spaken, och den är valfri snarare än obligatorisk. Vägspecifika översatta identiteter kan styra svar tillbaka till den gateway som håller tillståndet, vilket är en legitim design. De lägger dock till mappningar, returvägar och en ägare av det tillståndet, så acceptera bördan bara för ett krav du kan säga högt.

Om kravet bara är att båda vägarna bär trafik och att en av dem överlever förlusten av en leverantör, är vanlig multipath per flöde med sammanhängande returrouting oftast den mindre designen.

Gå igenom acceptansen i ordning

Testa i den här ordningen och notera adresserna vid varje steg: en ny anslutning på väg A och dess svarsväg, samma sak på väg B, sedan förlust av en leverantör, sedan återställning. För varje resultat, notera vilka etablerade flöden som flyttades, vilka som måste återansluta och vart nya flöden gick efteråt. Skriv ned förväntat värde först och jämför det sedan med fångsten. Två etablerade tunnlar bevisar ingenting av det.

Designen är klar när tabellen du skrev stämmer med det fångsten visar, inte när båda tunnlarna är uppe.