IPsec u IPsec-u: koje adrese mora nositi vanjski tunel

Dajte vanjskom tunelu adrese unutrašnjih gatewaya, a ne podmreže aplikacija. Zatim dokažite forwarding, translaciju i MTU na svakom sloju prije nego to nazovete ugniježđenim.

Ugniježđeni IPsec lakše je razumjeti kada dva sloja završavaju na različitim mašinama. Četiri gatewaya, dva tunela i jedno pitanje koje odlučuje radi li dizajn: šta vanjski tunel zapravo vidi kada unutrašnji završi s paketom? Odgovorite na to i selektori, rute i redoslijed rješavanja problema slijede. Pogriješite i potrošit ćete dan na debagovanje tunela koji je tehnički aktivan.

Model s četiri gatewaya

Vanjski gatewayi A i B grade prvi tunel između dvije lokacije. Iza A stoji unutrašnji gateway C s tranzitnom adresom 10.60.0.2; iza B stoji unutrašnji gateway D s tranzitnom adresom 10.70.0.2. Aplikacijske mreže žive iza C i D, a svaka adresa u primjeru namjerno se ne preklapa.

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

Podjela slojeva na četiri hosta znači da svaka mašina provodi jednu granicu. Jedan host koji pokreće oba sloja mora uskladiti dva skupa politika, dvije routing tablice i dva načina kvara na jednoj mašini, što je moguće i mnogo teže uočiti.

Svaki sloj uklanja samo svoju zaštitu

C šifrira aplikacijski paket za D. Rezultat je adresiran od C prema D i to je ono što stiže do A. Sve nizvodno zavisi od tog prepisivanja.

A ga ponovo šifrira za B. B dešifrira vanjski sloj, vidi paket od C prema D i prosljeđuje ga još uvijek šifrovanog. D uklanja unutrašnju zaštitu i dostavlja aplikacijski paket.

Dakle A i B vide unutrašnje krajnje tačke i njihove metapodatke, ali nisu strane koje dešifriraju aplikacijski payload. To je stvarno svojstvo dizajna, a ne tvrdnja da su C, D ili aplikacijski hostovi pouzdani.

Vanjski selektori imenuju unutrašnje gatewaye

Ovdje većina ovakvih gradnji pada. Za vanjski tunel zasnovan na politikama, selektori koje pregovarate moraju sadržavati adrese kojima A i B stvarno rukuju: 10.60.0.2/32 i 10.70.0.2/32, u ispravnom lokalnom i udaljenom redu.

Stavljanje konačnih aplikacijskih podmreža u vanjske selektore ne radi, jer dok paket stigne do A, unutrašnja enkapsulacija je već prepisala ono što A mora zaštititi. Vanjska politika tada ne bi ništa pogodila, a tunel bi se podigao ne noseći podatke.

Ne sužavajte vanjsku dozvolu na UDP 500. Unutrašnja veza ima svoj data path, koji koristi ESP ili UDP enkapsulaciju zavisno od toga šta je pregovarala, a vanjska politika mora dozvoliti taj protokol.

Provjerite rezultat pomoću swanctl --list-sas na svakom gatewayu i potvrdite da child sigurnosne asocijacije prijavljuju adrese koje ste namjeravali, a ne one koje ste pretpostavili. Ako lista prikazuje aplikacijske podmreže, vanjska politika je napisana za pogrešan sloj. Popravite selektore prije nego što debagujete routing, jer routing će izgledati ispravno, a brojači se neće pomjerati.

Forwarding i zamka rekurzije

Selektori ne zamjenjuju routing. A i B moraju prosljeđivati saobraćaj između C i D u oba smjera, što znači omogućen IP forwarding, rute koje pokazuju na tunel i povratni put koji postoji na drugoj strani.

Ako vanjski tunel koristi XFRM interfejse, rute biraju interfejs dok pregovarane politike još uvijek ograničavaju šta nosi. Interfejs ne proširuje zaštićeno; samo mijenja kako kernel preuzima paket.

Zamka je rekurzija. Ruta A do vanjske krajnje tačke B mora slijediti underlay, a ne tunel koji A uspostavlja, inače enkapsulacija pokušava putovati unutar sebe i veza se nikada ne završava.

Pregledajte translaciju prije dodavanja slojeva

Pogledajte svaki source NAT na A i B prije nego što bilo šta drugo podesite. Pravilo koje prepisuje adresu C prije primjene IPsec politike može slomiti dogovorene selektore, a može i promijeniti šta D prima na drugoj strani.

Široki masquerading ne postaje sigurniji zbog dva sloja. On skriva koju adresu vidi udaljena strana, a to je upravo informacija koja vam treba kada je tunel aktivan, a aplikacija ne radi.

Ako je NAT pravilo zaista potrebno, zapišite s kojom adresom svaka strana misli da razgovara. Taj jedan red rješava većinu rasprava o tome je li kriv tunel ili translacija. Također govori sljedećem inženjeru gdje da gleda kada pravilo bude uklonjeno nakon godinu dana. Ping neće učiniti ništa od toga.

Dokažite fail-closed i provjerite MTU

Nestanak rute sam po sebi nije fail-closed politika. Druga tablica, default ruta ili pravilo politike mogu tiho pružiti fallback, a jedini način da to saznate je da spustite vanjski tunel i posmatrate šta radi aplikacijski saobraćaj. Uradite to namjerno, u prozoru, umjesto da to otkrijete slučajno.

Testirajte tri stanja: vanjski tunel spušten, unutrašnji tunel spušten i oporavak nakon što se oba vrate. Koristite brojače politika na svakom gatewayu, jer dvije uspostavljene IKE sesije dokazuju samo da je pregovaranje kontrolne ravni uspjelo.

Predvidite budžet i za obje enkapsulacije. Radni IKE rezultat je malih paketa, a aplikacijski paketi pune veličine još uvijek mogu pasti kada se dodaju dva zaglavlja; testirajte s poznatom veličinom payloada na stvarnoj putanji umjesto da pretpostavljate da se brojevi sabiraju. Aritmetika je laka, putanja nije.

Povezani članci