IPsec у IPsec-у: које адресе мора да носи спољашњи тунел

Дајте спољашњем тунелу адресе унутрашњих гејтвеја, а не подмреже апликација. Затим докажите прослеђивање, превод и MTU на сваком слоју пре него што то назовете угнежђеним.

Угнежђени IPsec је лакше разумети када два слоја завршавају на различитим машинама. Четири гејтвеја, два тунела и једно питање које одлучује да ли пројекат ради: шта спољашњи тунел заиста види када унутрашњи заврши са пакетом? Одговорите на то и селектори, руте и редослед решавања проблема следе. Погрешите и потрошићете дан на отклањање грешака у тунелу који је технички активан.

Модел са четири гејтвеја

Спољашњи гејтвеји A и B граде први тунел између две локације. Иза A се налази унутрашњи гејтвеј C са транзитном адресом 10.60.0.2; иза B се налази унутрашњи гејтвеј D са транзитном адресом 10.70.0.2. Апликационе мреже живе иза C и D, и свака адреса у примеру намерно се не преклапа.

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

Подела слојева на четири хоста значи да свака машина спроводи једну границу. Један хост који покреће оба слоја мора да усагласи два скупа политика, две табеле рутирања и два режима отказа на једној машини, што је могуће и много теже приметити.

Сваки слој уклања само своју заштиту

C шифрује апликациони пакет за D. Резултат је адресиран од C ка D, и то је оно што стиже до A. Све даље зависи од тог преписивања.

A га поново шифрује за B. B дешифрује спољашњи слој, види пакет од C ка D и прослеђује га још увек шифрованог. D уклања унутрашњу заштиту и доставља апликациони пакет.

Дакле A и B виде унутрашње крајње тачке и њихове метаподатке, али нису стране које дешифрују корисни терет апликације. То је стварна особина дизајна, а не тврдња да су C, D или апликациони хостови поуздани.

Спољашњи селектори именују унутрашње гејтвеје

Овде већина оваквих конструкција пропада. За спољашњи тунел заснован на политикама, селектори које преговарате морају да садрже адресе којима A и B заиста управљају: 10.60.0.2/32 и 10.70.0.2/32, у исправном локалном и удаљеном редоследу.

Стављање коначних апликационих подмрежа у спољашње селекторе не ради, јер када пакет стигне до A, унутрашња инкапсулација је већ преписала оно што A мора да заштити. Спољашња политика тада не би одговарала ничему, и тунел би се подигао без преноса података.

Не сужавајте спољашњу дозволу на UDP 500. Унутрашња веза има сопствену путању података, која користи ESP или UDP инкапсулацију зависно од тога шта је преговарано, и спољашња политика мора да дозволи тај протокол.

Проверите резултат помоћу swanctl --list-sas на сваком гејтвеју и потврдите да дечје безбедносне асоцијације пријављују адресе које сте намеравали, а не оне које сте претпоставили. Ако листа показује апликационе подмреже, спољашња политика је написана за погрешан слој. Исправите селекторе пре отклањања грешака у рутирању, јер рутирање ће изгледати исправно, а бројачи се неће померити.

Прослеђивање и замка рекурзије

Селектори не замењују рутирање. A и B морају да прослеђују саобраћај између C и D у оба смера, што значи омогућено IP прослеђивање, руте које показују на тунел и повратни пут који постоји на другој страни.

Ако спољашњи тунел користи XFRM интерфејсе, руте бирају интерфејс док преговаране политике још увек ограничавају шта он носи. Интерфејс не проширује заштићено; само мења начин на који језгро преузима пакет.

Замка је рекурзија. Рута A до спољашње крајње тачке B мора да прати доњу мрежу, а не тунел који A гради, иначе инкапсулација покушава да путује унутар себе и веза се никада не завршава.

Прегледајте превод пре додавања слојева

Погледајте сваки изворни NAT на A и B пре него што подесите било шта друго. Правило које преписује адресу C пре примене IPsec политике може да поквари договорене селекторе, а може и да промени шта D прима на другој страни.

Широко маскирање не постаје безбедније због два слоја. Оно скрива коју адресу види удаљена страна, а то је управо информација која вам је потребна када је тунел активан, а апликација није.

Ако је NAT правило заиста потребно, запишите са којом адресом свака страна мисли да разговара. Та једна линија решава већину расправа о томе да ли је крив тунел или превод. Такође каже следећем инжењеру где да гледа када правило буде уклоњено после годину дана. Ping неће урадити ништа од тога.

Докажите fail-closed и проверите MTU

Нестанак руте сам по себи није fail-closed политика. Друга табела, подразумевана рута или правило политике могу тихо да пруже резервну путању, и једини начин да то сазнате је да спустите спољашњи тунел и посматрате шта ради апликациони саобраћај. Урадите то намерно, у прозору, уместо да то откријете случајно.

Тестирајте три стања: спољашњи тунел спуштен, унутрашњи тунел спуштен и опоравак након што се оба врате. Користите бројаче политика на сваком гејтвеју, јер две успостављене IKE сесије доказују само да је преговарање на контролној равни успело.

Предвидите буџет за обе инкапсулације. Функционалан IKE је резултат малих пакета, а апликациони пакети пуне величине ипак могу да не прођу када се додају два заглавља; тестирајте са познатом величином носивости на стварној путањи уместо да претпостављате да се бројеви сабирају. Аритметика је лака, путања није.

Повезани чланци