Twa aktive IPsec-tunnels hawwe noch altyd in weromweiplan nedich
Twa tunnels binne gjin plan. Folgje ien TCP-petear útein troch ien pear poarten en werom troch in oar, en beslút dan wa't de tastân hâldt.
Meitsje in terminal iepen op in wurkstasjon by it iene plak en ferbynje mei in tsjinner by it oare. Dat iene TCP-petear moat no fjouwer poarten oerstekke ynstee fan twa, en it nijsgjirrige diel is net oft it op in goede dei wurket. It nijsgjirrige diel is hokker pear poarten de rjochting foarút keas, hokker pear it antwurd kiest, en wa't de tastân foar de streaming hâldt wylst dat bart. Neat yn 'e rûtetabel beslút dat foar dy.
Tekenje fjouwer poarten foardatst in rûte tekenest
In dûbelaktyf ûntwerp mei twa ûnôfhinklike VPN-firewalls per plak, ien pear per provider, jout dy twa brûkbere paden en trije manieren om se te brekken. Skriuw de adressen op foardatst eat konfigurearrest: de klant sa't dy te sjen is foar en nei elke poarte, de tsjinner likegoed, de folgjende hop foarút en de folgjende hop werom.
Dy tabel is it ûntwerp. Alles dêrnei is in fraach oft de apparaten it mei de tabel iens binne.
Hoe't it paad foarút keazen wurdt
In multipath-routinglaach mei gelikense kosten ferdielt streams oer de folgjende hops troch headerfjilden te hashen, wat RFC 2992 yn detail beskriuwt. Dy seleksje kin folslein tastânleas wêze: it hat gjin ynfier foar ferbiningstracking nedich, allinich in stabile hash oer ûnferoare fjilden. Hâld de paadset en de hash-ynfieren konstant, en elk pakket fan 'e stream kiest deselde folgjende hop.
Seleksje per stream foarkomt de weroardering dy't pakket-foar-pakket-balâns jaan soe oer keppelingen mei ferskillende fertragingen. It ûnthjit net dat gelikense routingkosten gelikense metten latentens betsjutte, want dat dogge se net. En as de paadsamling feroaret, wurde streams opnij mapt, dus it oerlibjen fan ferbiningen by in stoaring is in aparte eask fan paadseleksje.
Wat de weromwei wier nedich hat
Hjir hâldt de kuier op om symmetrysk te wêzen. In stabile hash foarút fertelt dy neat oer wat it fiere plak mei it antwurd dwaan sil. As in ûnôfhinklike firewall beide rjochtingen fan 'e ferbining sjen moat om brûkbere tastân te hâlden, lit in weromrûte dy't him foarbygiet ferkear efter dat nearne mei oerienkomt. Twa kasten mei ferlykbere regelssets binne gjin dielde tastân.
Befêstigje it ymplemintearre twarjochtingsgedrach, of skriuw eksplisyt belied dat de fereaske grinzen gearhingjend hâldt. In gissing hjir wurdt by in stoaring ûntdutsen, troch minsken dy't dêr net fan genietsje.
Wêr't oersetting foar dy beslút
NAT is de oare hefbeam, en it is opsjoneel ynstee fan ferplicht. Paadspesifike oersetten identiteiten kinne antwurden weromstjoere nei de poarte dy't de tastân hâldt, wat in legitime ûntwerp is. Se foegje ek mappings, weromrûtes en in eigner foar dy tastân ta, dus akseptearje de lêst allinich foar in eask dy'tst hurdop neame kinst.
As de eask gewoan is dat beide paden ferkear drage en ien fan beide in providerferlies oerlibbet, is gewoane multipath per stream mei gearhingjende weromrouting meastal it lytsere ûntwerp.
Rin de akseptaasje yn folchoarder troch
Test yn dizze folchoarder en skriuw de adressen by elke stap op: in nije ferbining op paad A en syn antwurdpaad, itselde op paad B, dan ferlies fan ien provider, dan werstel. Skriuw by elk resultaat op hokker fêstige streams ferhuze, hokker opnij ferbine moasten en wêr't nije streams dêrnei hinne giene. Skriuw earst de ferwachte wearde op en fergelykje dy dan mei de opname. Twa fêstige tunnels bewize dêr neat fan.
It ûntwerp is klear as de tabel dy'tst skreaun hast oerienkomt mei wat de opname lit sjen, net as beide tunnels oan binne.