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 изгражда, иначе инкапсулацията се опитва да пътува вътре в себе си и връзката никога не завършва.

Проверете транслацията, преди да добавяте слоеве

Разгледайте всеки source NAT на A и B, преди да настроите нещо друго. Правило, което презаписва адреса на C преди прилагане на IPsec политиката, може да счупи договорените селектори и също да промени какво получава D от другата страна.

Широкият маскарад не става по-сигурен от два слоя. Той скрива кой адрес вижда далечната страна, а това е точно информацията, която ви трябва, когато тунелът е активен, а приложението не работи.

Ако правило за NAT наистина е необходимо, запишете с кой адрес всяка страна смята, че говори. Този един ред решава повечето спорове дали тунелът или транслацията е виновен. Той също казва на следващия инженер къде да гледа, когато правилото бъде премахнато след година. Ping няма да направи нищо от това.

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

Изчезването на маршрут сам по себе си не е fail-closed политика. Друга таблица, маршрут по подразбиране или правило за политика могат тихо да осигурят резервен път и единственият начин да разберете е да свалите външния тунел и да наблюдавате какво прави трафикът на приложенията. Правете го нарочно, в прозорец, вместо да го откриете случайно.

Тествайте три състояния: външен тунел свален, вътрешен тунел свален и възстановяване, след като и двата се върнат. Използвайте броячи на политики на всеки шлюз, защото две установени IKE сесии доказват само, че договарянето на контролната равнина е успяло.

Предвидете бюджет и за двете инкапсулации. Работещият IKE е резултат при малки пакети, а пълноразмерните пакети на приложенията все още могат да се провалят, след като се добавят два заглавки; тествайте с известен размер на полезния товар по реалния път, вместо да предполагате, че числата се събират. Аритметиката е лесна, пътят не е.

Подобни статии