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 вынік для дробных пакетаў, а пакеты праграм поўнага памеру ўсё яшчэ могуць не прайсці, калі дадаюцца два загалоўкі; правярайце з вядомым памерам карыснай нагрузкі на рэальным шляху, а не мяркуйце, што лічбы супадуць. Арыфметыка простая, а шлях не.