Dva aktivna IPsec tunela i dalje traže plan povratnog puta

Otvori terminal na radnoj stanici na jednoj lokaciji i poveži se na server na drugoj. Taj jedan TCP razgovor sada mora proći kroz četiri prolaza umjesto dva, a zanimljivi dio nije to da li radi na dobar dan. Zanimljivi dio je koji par prolaza je odabrala smjer naprijed, koji par bira odgovor i ko drži stanje toka dok se to dešava. Ništa u tabeli ruta ne odlučuje to umjesto vas.

Nacrtaj četiri prolaza prije nego nacrtaš rutu

Dvostruko aktivni dizajn s dva nezavisna VPN firewalla po lokaciji, jedan par po ISP-u, daje ti dvije upotrebljive staze i tri načina da ih pokvariš. Zapiši adrese prije nego bilo šta konfigurišeš: klijent kako se vidi prije i poslije svakog prolaza, server isto tako, sljedeći hop naprijed i sljedeći hop nazad.

Ta tabela je dizajn. Sve poslije nje pitanje je da li se uređaji slažu s tabelom.

Kako se bira put naprijed

Sloj višestaznog rutiranja s jednakom cijenom raspoređuje tokove po sljedećim hopovima heširanjem polja zaglavlja, što RFC 2992 detaljno opisuje. Taj izbor može biti potpuno bezstanjan: ne treba mu unos praćenja konekcije, samo stabilan heš nad nepromijenjenim poljima. Drži skup staza i ulaze heša konstantnim i svaki paket toka bira isti sljedeći hop.

Odabir po toku izbjegava preraspoređivanje koje bi balansiranje paket po paket izazvalo na vezama s različitim kašnjenjima. On ne obećava da jednaka cijena rutiranja znači jednako izmjereno kašnjenje, jer ne znači. A kada se sastav staza promijeni, tokovi se premapiraju, pa je preživljavanje konekcije tokom kvara poseban zahtjev od odabira staze.

Šta povratni put zaista treba

Ovdje šetnja prestaje biti simetrična. Stabilan heš naprijed ne govori ti ništa o tome šta će udaljena lokacija uraditi s odgovorom. Ako nezavisni firewall mora vidjeti oba smjera konekcije da bi održao korisno stanje, povratna ruta koja ga zaobilazi ostavlja saobraćaj koji se ni s čim ne poklapa. Dvije kutije sa sličnim skupovima pravila nisu dijeljeno stanje.

Potvrdi implementirano dvosmjerno ponašanje ili napiši izričitu politiku koja održava tražene granice koherentnim. Pretpostavka se ovdje otkrije tokom ispada, od ljudi koji u tome ne uživaju.

Gdje prijevod odlučuje umjesto tebe

NAT je druga poluga i nije obavezan nego opcionalan. Prevedeni identiteti specifični za stazu mogu usmjeriti odgovore nazad ka prolazu koji drži stanje, što je legitiman dizajn. Oni takođe dodaju mapiranja, povratne rute i vlasnika tog stanja, pa prihvati teret samo za zahtjev koji možeš izgovoriti naglas.

Ako je zahtjev jednostavno da obje staze nose saobraćaj i da bilo koja preživi gubitak ISP-a, običan višestazni tok s koherentnim povratnim rutiranjem obično je manji dizajn.

Prođi prihvatanje po redu

Testiraj ovim redoslijedom i bilježi adrese na svakom koraku: nova konekcija na stazi A i njen povratni put, isto na stazi B, zatim gubitak jednog ISP-a, zatim obnova. Za svaki rezultat zabilježi koji su se uspostavljeni tokovi pomjerili, koji su se morali ponovo povezati i gdje su novi tokovi otišli poslije. Prvo zapiši očekivanu vrijednost, pa je uporedi sa snimkom. Dva uspostavljena tunela ne dokazuju ništa od toga.

Dizajn je gotov kada se tabela koju si napisao poklapa s onim što snimak pokazuje, a ne kada su oba tunela podignuta.