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 е резултат на мали пакети, а апликациските пакети со полна големина сѐ уште можат да не поминат кога ќе се додадат два заглавија; тестирајте со позната големина на товар на вистинската патека наместо да претпоставувате дека бројките се собираат. Аритметиката е лесна, патеката не е.

Поврзани статии