To aktive IPsec-tunnelar treng framleis ein plan for returvegen

Opne ein terminal på ein arbeidsstasjon på den eine staden og kople til ein tenar på den andre. Den eine TCP-samtalen må no krysse fire gatewayar i staden for to, og den interessante delen er ikkje om det verkar på ein god dag. Den interessante delen er kva gateway-par retninga ut valde, kva par svaret vel, og kven som held tilstanden for straumen medan det skjer. Ingenting i rutetabellen avgjer det for deg.

Teikn fire gatewayar før du teiknar ei rute

Eit dobbeltaktivt design med to uavhengige VPN-brannmurar per stad, eitt par per leverandør, gjev deg to brukbare vegar og tre måtar å bryte dei på. Skriv ned adressene før du konfigurerer noko: klienten slik han blir sett før og etter kvar gateway, tenaren likeins, neste hopp ut og neste hopp tilbake.

Den tabellen er designet. Alt etter han er eit spørsmål om einingane er samde med tabellen.

Korleis vegen ut blir vald

Eit multipath-rutinglag med lik kostnad fordeler straumar over dei neste hoppa ved å hashe headerfelt, noko RFC 2992 skildrar i detalj. Det valet kan vere heilt tilstandslaus: det treng ingen oppføring for tilkoplingsovervaking, berre ein stabil hash over uendra felt. Hald vegsettet og hash-inndataa konstante, og kvar pakke i straumen vel den same neste hoppet.

Val per straum unngår omorganiseringa som pakke-for-pakke-balanse ville føre til på lenkjer med ulik forseinking. Det lovar ikkje at lik rutekostnad tyder lik målt latenstid, for det gjer han ikkje. Og når samansetjinga av vegane endrar seg, blir straumar remappa, så at sambandet overlever under ein feil er eit eige krav frå vegval.

Kva returvegen faktisk treng

Her sluttar gjennomgangen å vere symmetrisk. Ein stabil hash utover fortel deg ingenting om kva den fjerne staden vil gjere med svaret. Viss ein uavhengig brannmur må sjå begge retningane av sambandet for å halde nyttig tilstand, lèt ein returveg som går utanom han etter trafikk som ikkje samsvarar med noko i det heile. To boksar med like regelsett er ikkje delt tilstand.

Stadfest den implementerte tovegsåtferda, eller skriv ein uttrykkeleg policy som held dei naudsynte grensene samanhengande. Ein antaking her blir oppdaga under eit avbrot, av folk som ikkje nyt det.

Der omsetjinga avgjer for deg

NAT er den andre spaken, og han er valfri snarare enn påkravd. Vegspesifikke omsette identitetar kan styre svar tilbake til gatewayen som held tilstanden, noko som er eit legitimt design. Dei legg òg til mappingar, returvegar og ein eigar av den tilstanden, så godta byrda berre for eit krav du kan seie høgt.

Viss kravet berre er at begge vegane ber trafikk og at ein av dei overlever tapet av ein leverandør, er vanleg multipath per straum med samanhengande returruting oftast det mindre designet.

Gå gjennom akseptansen i rekkjefølgje

Test i denne rekkjefølgja og noter adressene ved kvart steg: eit nytt samband på veg A og returvegen hans, det same på veg B, deretter tap av éin leverandør, deretter attoppretting. For kvart resultat, noter kva etablerte straumar som flytta seg, kva som måtte kople til på nytt, og kvar nye straumar gjekk etterpå. Skriv ned forventa verdi først, og samanlikn han så med opptaket. To etablerte tunnelar bevisar ingenting av det.

Designet er ferdig når tabellen du skreiv stemmer med det opptaket viser, ikkje når begge tunnelane er oppe.