Treba li router između dva IPsec partnera IPsec?

Laboratorijska vježba koja kaže „konfiguriraj IPsec između dvije lokacije“ skriva dva različita posla. Dvije krajnje točke završavaju tunel: pregovaraju, provjeravaju identitet, šifriraju i dešifriraju. Svaki router između prosljeđuje pakete čije vanjsko zaglavlje pripada krajnjim točkama, i to čini ne znajući da tunel postoji.

Odrediti koji se posao traži od uređaja prvi je korak vježbe. Većina zabune u laboratorijskim izvještajima, i dobar dio zabune u produkcijskim dijagramima, dolazi od toga što se „podržava IPsec“ tretira kao jedno svojstvo umjesto dva.

Prosljeđivanje nije završavanje

U tunelskom načinu rada, vanjsko IP zaglavlje adresirano je na uređaje koji završavaju tunel. Router u sredini traži odredište i prosljeđuje, isto kao za bilo koji drugi paket, a korisni teret koji nosi za njega je neproziran.

Ta neprozirnost je namjerna. Router ne čuva partnerovu tajnu, ne vodi pregovore i ne treba mu baza politika. Treba mu put do udaljene krajnje točke i dopuštenje da proslijedi paket.

Miješanje toga dvoga dovodi do stvarnih pogrešaka: traženje od tranzitnog vatrozida da „dopusti IPsec“, kad je stvarni zahtjev dopustiti protokol 50 između određenih adresa, ili očekivanje da će posredni uređaj dešifrirati radi inspekcije kad nema ključ.

Što posredni uređaj ipak mora učiniti ispravno

Prosljeđivanje ima svoje zahtjeve. Rute moraju dosegnuti oba vanjska krajnja odredišta, a svaka politika duž puta mora dopustiti stvarni vanjski promet, a ne pretpostavljeni broj portova. Pravilo napisano prema TCP 443 jer je netko pretpostavio TLS neće se poklopiti s protokolom 50.

Izvorni ESP je IP protokol 50. Nije TCP 50 ni UDP 50, a pravilo koje blokira promet koji nije TCP odbacit će ga. Ako projekt koristi UDP inkapsulaciju, vidljivi transport prelazi na port inkapsulacije, a politika mora odgovarati odabranom projektu.

Važna je i veličina paketa. Ruta koja nosi malu sondu ne dokazuje da cijela inkapsulirana razmjena stane. Put koji odbacuje velike pakete može dopustiti da pregovori uspiju, a radni opterećenje ne uspije, što izgleda kao problem aplikacije. Testirajte prometom veličine stvarnog opterećenja prije nego optužite tunel.

Zašto simulator mijenja pitanje

Simulator nije router s kraćim popisom funkcija; to je model s dokumentiranim podskupom i vlastitim pravilima o tome što se određeni uređaj može konfigurirati da radi. Često postavljana pitanja za Cisco Packet Tracer jasno navode da su uređaji i protokoli pojednostavljeni modeli.

Tako pitanje postaje tri pitanja. Prosljeđuje li simulirani uređaj pakete koji su potrebni scenariju? Nudi li isti uređaj konfiguracijsku površinu koju lekcija pretpostavlja? I znači li prihvaćena naredba da se ponašanje doista simulira ili samo analizira?

Naredba koja nedostaje može biti ograničenje modela, a ne pogreška u vašoj konfiguraciji. Prisutna naredba može prihvatiti sintaksu bez reprodukcije svakog produkcijskog ponašanja. Provjerite pomoć uređaja instalirane verzije prije nego zaključite u bilo kojem smjeru.

Pisanje uvjeta za uspjeh za laboratorij

Za lekciju o underlayu, uvjet za uspjeh je dostupnost krajnjih točaka plus vanjski paketi koji prolaze kroz posredni uređaj. Dokažite to brojačima samog simulatora ili prikazom paketa i navedite protokol koji očekujete.

Za lekciju o IPsec-u dodajte stanje pregovora i jedan zaštićeni tok od LAN-a do LAN-a. Ako simulator prikazuje sigurnosne asocijacije, zabilježite ih. Ako ne, napišite to u izvještaju umjesto da nagovještavate da je tunel verificiran.

Čuvajte verziju simulatora, odabrane uređaje i cilj učenja uz datoteku topologije. Upravo taj zapis omogućuje nekome drugome da ponovi vježbu i razumije koji su dijelovi modelirani.

Produkcijska konfiguracija zahtijeva vlastite dokaze o platformi. Zeleni simulirani paket je nastavni rezultat, a ne izjava o kompatibilnosti s hardverom koji ćete uvesti.