To aktive IPsec-tunneler har stadig brug for en returvejsplan

Åbn en terminal på en arbejdsstation på det ene sted, og opret forbindelse til en server på det andet. Den ene TCP-samtale skal nu krydse fire gateways i stedet for to, og den interessante del er ikke, om det virker på en god dag. Den interessante del er, hvilket par gateways retningen frem valgte, hvilket par svaret vælger, og hvem der holder tilstand for strømmen, mens det sker. Intet i routingtabellen beslutter det for dig.

Tegn fire gateways, før du tegner en rute

Et dobbeltaktivt design med to uafhængige VPN-firewalls for hvert sted, et par for hver udbyder, giver dig to brugbare stier og tre måder at bryde dem på. Skriv adresserne ned, før du konfigurerer noget: klienten som set før og efter hver gateway, serveren ligeså, det næste hop frem og det næste hop tilbage.

Den tabel er designet. Alt derefter er et spørgsmål om, hvorvidt enhederne er enige med tabellen.

Hvordan stien frem bliver valgt

Et multipath-routinglag med samme omkostning fordeler strømme ud over de næste hop ved at hashe headerfelter, hvilket RFC 2992 beskriver i detaljer. Det valg kan være helt tilstandsløst: det kræver ingen post for forbindelsessporing, kun en stabil hash over uændrede felter. Hold stisættet og hash-input konstant, og hver pakke i strømmen vælger det samme næste hop.

Valg for hver strøm undgår den omorganisering, som pakke-for-pakke-balancering ville forårsage på links med forskellige forsinkelser. Det lover ikke, at ens routingomkostning betyder ens målt latenstid, for det gør den ikke. Og når stiernes sammensætning ændres, remappes strømme, så forbindelsens overlevelse under et svigt er et separat krav fra stivalg.

Hvad returvejen faktisk har brug for

Her holder gennemgangen op med at være symmetrisk. En stabil hash frem fortæller dig intet om, hvad det fjerne sted vil gøre med svaret. Hvis en uafhængig firewall skal se begge retninger af forbindelsen for at opretholde brugbar tilstand, efterlader en returrute, der omgår den, trafik, der ikke matcher noget som helst. To bokse med ens regelsæt er ikke delt tilstand.

Bekræft den implementerede tovejsadfærd, eller skriv en udtrykkelig politik, der holder de krævede grænser sammenhængende. En gættevurdering her bliver opdaget under et nedbrud, af folk, der ikke nyder det.

Hvor oversættelse beslutter for dig

NAT er det andet håndtag, og det er valgfrit snarere end påkrævet. Stispecifikke oversatte identiteter kan styre svar tilbage til den gateway, der holder tilstanden, hvilket er et legitimt design. De tilføjer også mappinger, returruter og en ejer af den tilstand, så accepter byrden kun for et krav, du kan sige højt.

Hvis kravet blot er, at begge stier bærer trafik, og at en af dem overlever tab af en udbyder, er almindelig multipath for hver strøm med sammenhængende returrouting normalt det mindre design.

Gå accepten igennem i rækkefølge

Test i denne rækkefølge, og noter adresserne ved hvert trin: en ny forbindelse på sti A og dens svarrute, det samme på sti B, derefter tab af en udbyder, derefter genoprettelse. For hvert resultat skal du notere, hvilke etablerede strømme der flyttede sig, hvilke der måtte genoprette forbindelsen, og hvor nye strømme gik hen bagefter. Skriv den forventede værdi ned først, og sammenlign den så med optagelsen. To etablerede tunneler beviser intet af det.

Designet er færdigt, når den tabel, du skrev, stemmer med det, optagelsen viser, ikke når begge tunneler er oppe.