To aktive IPsec-tunneler trenger fortsatt en plan for returveien

Åpne en terminal på en arbeidsstasjon på det ene stedet og koble til en server på det andre. Den ene TCP-samtalen må nå krysse fire gateways i stedet for to, og den interessante delen er ikke om det virker på en god dag. Den interessante delen er hvilket gateway-par retningen ut valgte, hvilket par svaret velger, og hvem som holder tilstanden for strømmen mens det skjer. Ingenting i rutingtabellen bestemmer det for deg.

Tegn fire gateways før du tegner en rute

Et dobbeltaktivt design med to uavhengige VPN-brannmurer per sted, ett par per leverandør, gir deg to brukbare veier og tre måter å bryte dem på. Skriv ned adressene før du konfigurerer noe: klienten slik den ses før og etter hver gateway, serveren likeså, neste hopp ut og neste hopp tilbake.

Den tabellen er designet. Alt etter den er et spørsmål om enhetene er enige med tabellen.

Hvordan veien ut blir valgt

Et multipath-rutinglag med lik kostnad fordeler strømmer over de neste hoppene ved å hashe headerfelt, noe RFC 2992 beskriver i detalj. Det valget kan være helt tilstandsløst: det trenger ingen oppføring for tilkoblingssporing, bare en stabil hash over uendrede felt. Hold veisettet og hash-inndataene konstante, og hver pakke i strømmen velger det samme neste hoppet.

Valg per strøm unngår omorganiseringen som pakke-for-pakke-balanse ville føre til på lenker med ulik forsinkelse. Det lover ikke at lik rutingkostnad betyr lik målt latenstid, for det gjør den ikke. Og når veienes sammensetning endres, remappes strømmer, så at forbindelsen overlever under en feil er et eget krav fra veivalg.

Hva returveien faktisk trenger

Her slutter gjennomgangen å være symmetrisk. En stabil hash utover forteller deg ingenting om hva det fjerne stedet vil gjøre med svaret. Hvis en uavhengig brannmur må se begge retninger av forbindelsen for å opprettholde nyttig tilstand, lar en returvei som går utenom den trafikk som ikke samsvarer med noe i det hele tatt. To bokser med like regelsett er ikke delt tilstand.

Bekreft den implementerte toveisatferden, eller skriv en uttrykkelig policy som holder de nødvendige grensene sammenhengende. En antakelse her blir oppdaget under et avbrudd, av folk som ikke nyter det.

Der oversettelsen bestemmer for deg

NAT er den andre spaken, og den er valgfri snarere enn påkrevd. Veispesifikke oversatte identiteter kan styre svar tilbake til gatewayen som holder tilstanden, noe som er et legitimt design. De legger også til mappinger, returveier og en eier av den tilstanden, så aksepter byrden bare for et krav du kan si høyt.

Hvis kravet bare er at begge veiene bærer trafikk og at en av dem overlever tapet av en leverandør, er vanlig multipath per strøm med sammenhengende returruting vanligvis det mindre designet.

Gå gjennom akseptansen i rekkefølge

Test i denne rekkefølgen og noter adressene ved hvert steg: en ny forbindelse på vei A og returveien dens, det samme på vei B, deretter tap av én leverandør, deretter gjenoppretting. For hvert resultat, noter hvilke etablerte strømmer som flyttet seg, hvilke som måtte koble til på nytt, og hvor nye strømmer gikk etterpå. Skriv ned forventet verdi først, og sammenlign den så med opptaket. To etablerte tunneler beviser ingenting av det.

Designet er ferdig når tabellen du skrev stemmer med det opptaket viser, ikke når begge tunnelene er oppe.