Twee aktiewe IPsec-tonnels het steeds 'n terugpadplan nodig

Maak 'n terminaal oop op 'n werkstasie by die een terrein en koppel aan 'n bediener by die ander. Daardie enkele TCP-gesprek moet nou vier poorte oorsteek in plaas van twee, en die interessante deel is nie of dit op 'n goeie dag werk nie. Die interessante deel is watter paar poorte die vorentoe-rigting gekies het, watter paar die antwoord kies, en wie toestand vir die vloei hou terwyl dit gebeur. Niks in die roetetabel besluit dit vir jou nie.

Teken vier poorte voordat jy 'n roete teken

'n Dubbel-aktiewe ontwerp met twee onafhanklike VPN-vuurmure per terrein, een paar per ISP, gee jou twee bruikbare paaie en drie maniere om hulle te breek. Skryf die adresse neer voordat jy enigiets opstel: die kliënt soos gesien voor en ná elke poort, die bediener net so, die volgende sprong vorentoe en die volgende sprong terug.

Daardie tabel is die ontwerp. Alles daarna is 'n vraag of die toestelle met die tabel saamstem.

Hoe die vorentoe-pad gekies word

'n Gelykkoste-multipad-roeteringlaag verdeel vloeie oor volgende spronge deur kopvelde te hash, wat RFC 2992 breedvoerig beskryf. Daardie keuse kan heeltemal toestandloos wees: dit het geen verbindingnaspeuring-inskrywing nodig nie, net 'n stabiele hash oor onveranderde velde. Hou die padversameling en die hash-insette konstant, en elke pakkie van die vloei kies dieselfde volgende sprong.

Vloei-per-vloei keuse vermy die herordening wat pakkie-vir-pakkie balansering oor skakels met verskillende vertragings sou veroorsaak. Dit belowe nie dat gelyke roeteringkoste gelyke gemete latensie beteken nie, want dit doen nie. En wanneer die padsamestelling verander, herkaart vloeie, so verbindingoorlewing tydens 'n fout is 'n aparte vereiste van padkeuse.

Wat die terugpad werklik nodig het

Hier hou die deurloop op om simmetries te wees. 'n Stabiele vorentoe-hash vertel jou niks oor wat die verre terrein met die antwoord gaan doen nie. As 'n onafhanklike vuurmuur beide rigtings van die verbinding moet sien om bruikbare toestand te hou, laat 'n terugroete wat dit omseil, verkeer niks pas nie. Twee bokse met soortgelyke reëlversamelings is nie gedeelde toestand nie.

Bevestig die geïmplementeerde tweerigting-gedrag, of skryf eksplisiete beleid wat die vereiste grense samehangend hou. 'n Gissing hier word tydens 'n onderbreking ontdek, deur mense wat dit nie geniet nie.

Waar vertaling vir jou besluit

NAT is die ander hefboom, en dit is opsioneel eerder as verpligtend. Padspesifieke vertaalde identiteite kan antwoorde terugstuur na die poort wat die toestand hou, wat 'n wettige ontwerp is. Hulle voeg ook kaarte, terugroetes en 'n eienaar vir daardie toestand by, so aanvaar die las net vir 'n vereiste wat jy hardop kan noem.

As die vereiste bloot is dat beide paaie verkeer dra en enigeen 'n ISP-verlies oorleef, is gewone vloei-per-vloei multipad met samehangende terugroetering gewoonlik die kleiner ontwerp.

Stap die aanvaarding in volgorde

Toets in hierdie volgorde en teken die adresse by elke stap aan: 'n vars verbinding op pad A en sy antwoordpad, dieselfde op pad B, dan verlies van een ISP, dan herstel. Vir elke resultaat, let op watter gevestigde vloeie geskuif het, watter moes herkoppel, en waar nuwe vloeie daarna gegaan het. Skryf die verwagte waarde eerste neer en vergelyk dit dan met die opname. Twee gevestigde tonnels bewys niks daarvan nie.

Die ontwerp is klaar wanneer die tabel wat jy geskryf het met die opname ooreenstem, nie wanneer albei tonnels op is nie.