Nyiss egy terminált az egyik helyszín munkaállomásán, és csatlakozz a másik helyszín szerveréhez. Ennek az egyetlen TCP-beszélgetésnek most négy átjárón kell átkelnie kettő helyett, és az érdekes rész nem az, hogy működik-e egy jó napon. Az érdekes az, hogy melyik átjárópárt választotta az előre irány, melyik párt választja a válasz, és ki tartja az állapotot a folyamhoz, miközben ez történik. Az útválasztási táblában semmi nem dönti el ezt helyetted.

Rajzolj négy átjárót, mielőtt útvonalat rajzolnál

A kétszeresen aktív kialakítás helyszínenként két független VPN-tűzfallal, szolgáltatónként egy párral két használható útvonalat és három módot ad arra, hogy elrontsd őket. Írd fel a címeket, mielőtt bármit beállítasz: az ügyfelet úgy, ahogy minden átjáró előtt és után látszik, a szervert ugyanígy, a következő ugrást előre és a következő ugrást visszafelé.

Az a táblázat a terv. Minden utána az a kérdés, hogy az eszközök egyetértenek-e a táblázattal.

Hogyan választódik ki az előre vezető útvonal

Az egyenlő költségű többutas útválasztási réteg a fejlécmezők hashelésével osztja el a folyamokat a következő ugrások között, amit a RFC 2992 részletesen leír. Ez a kiválasztás teljesen állapotmentes lehet: nem kell kapcsolatkövetési bejegyzés, csak egy stabil hash a változatlan mezőkön. Tartsd állandóan az útvonalkészletet és a hash bemeneteit, és a folyam minden csomagja ugyanazt a következő ugrást választja.

A folyamonkénti kiválasztás elkerüli az újrarendeződést, amelyet a csomagonkénti terheléselosztás okozna a különböző késleltetésű kapcsolatokon. Nem ígéri, hogy az egyenlő útválasztási költség egyenlő mért késleltetést jelent, mert nem jelent. És amikor az útvonalak összetétele változik, a folyamok újra leképeződnek, ezért a kapcsolat túlélése hiba esetén az útvonalválasztástól külön követelmény.

Mire van valóban szüksége a visszaútnak

Itt a séta megszűnik szimmetrikusnak lenni. Egy stabil előre irányuló hash semmit sem mond arról, mit fog a távoli helyszín a válasszal tenni. Ha egy független tűzfalnak a kapcsolat mindkét irányát látnia kell a hasznos állapot fenntartásához, az őt megkerülő visszaút olyan forgalmat hagy, amely semmivel sem egyezik. Két hasonló szabálykészletű doboz nem megosztott állapot.

Erősítsd meg a megvalósított kétirányú viselkedést, vagy írj kifejezett szabályzatot, amely a szükséges határokat koherensen tartja. Egy itteni találgatás kiesés közben derül ki, olyan emberek előtt, akik nem élvezik.

Ahol a fordítás dönt helyetted

A NAT a másik kar, és opcionális, nem kötelező. Az útvonal-specifikus lefordított identitások visszairányíthatják a válaszokat az állapotot tartó átjáróhoz, ami legitim terv. Ugyanakkor leképezéseket, visszautakat és tulajdonost adnak ahhoz az állapothoz, ezért csak olyan követelményért vállald a terhet, amelyet hangosan ki tudsz mondani.

Ha a követelmény egyszerűen az, hogy mindkét útvonal forgalmat hordozzon, és bármelyik túlélje egy szolgáltató elvesztését, akkor a koherens visszairányítású egyszerű folyamonkénti többutas megoldás általában a kisebb terv.

Járd végig az átvételt sorrendben

Tesztelj ebben a sorrendben, és jegyezd fel a címeket minden lépésnél: új kapcsolat az A útvonalon és annak válaszútja, ugyanez a B útvonalon, majd egy szolgáltató elvesztése, majd helyreállítás. Minden eredménynél jegyezd fel, mely létrejött folyamok mozdultak el, melyeknek kellett újracsatlakozniuk, és hová mentek az új folyamok utána. Először írd fel a várt értéket, aztán hasonlítsd össze a felvétellel. Két létrejött alagút ebből semmit sem bizonyít.

A terv akkor kész, amikor az általad írt táblázat megegyezik azzal, amit a felvétel mutat, nem amikor mindkét alagút fel van.

Kapcsolódó cikkek