IPsec ичиндеги IPsec: сырткы туннель кайсы даректерди алып жүрүшү керек

Сырткы туннелге ички шлюздардын даректерин бериңиз, колдонмолордун кошумча тармактарын эмес. Андан кийин аны ичине салынган деп атоодон мурун ар бир катмардагы жөнөтүүнү, которууну жана MTUну далилдеңиз.

Ичине салынган IPsec жөнүндө ойлонуу эки катмар ар башка машиналарда бүткөндө жеңил. Төрт шлюз, эки туннель жана долбоордун иштешин чечкен бир суроо: ички туннель пакетти бүткөндөн кийин сырткы туннель чындыгында эмнени көрөт? Ага жооп бериңиз, анан селекторлор, маршруттар жана көйгөйдү чечүү тартиби өзү келет. Жаңылышсаңыз, техникалык жактан көтөрүлгөн туннелди оңдоого бир күн сарптайсыз.

Төрт шлюздуу модель

Сырткы A жана B шлюздары эки аймактын ортосунда биринчи туннелди курат. Aнын артында транзиттик дареги 10.60.0.2 болгон ички C шлюзу, Bнин артында транзиттик дареги 10.70.0.2 болгон ички D шлюзу турат. Колдонмо тармактары 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 куруп жаткан туннелге эмес, төмөнкү тармакка таянышы керек, болбосо инкапсуляция өз ичинде жүрүүгө аракет кылат жана байланыш эч качан бүтпөйт.

Катмарларды кошуудан мурун которууну караңыз

Башка нерсени жөндөөдөн мурун A жана Bдеги ар кандай булак NATты караңыз. IPsec саясаты колдонулуудан мурун C дарегин кайра жазуучу эреже келишилген селекторлорду бузушу мүмкүн, ошондой эле D каршы тарапта эмнени аларын өзгөртүшү мүмкүн.

Кең маскировка эки катмар болгондуктан коопсуз боло бербейт. Ал алыс тараптын кайсы даректи көрөрүн жашырат, ал эми туннель күйүп, колдонмо иштебегенде дал ошол маалымат керек.

Эгер NAT эрежеси чындыгында керек болсо, ар бир тарап кайсы дарек менен сүйлөшөм деп ойлойорун жазыңыз. Ошол бир сап туннельби же которуубу күнөөлүү деген талаштын көбүн чечет. Ал ошондой эле кийинки инженерге эреже бир жылдан кийин алынганда кайда кароону айтат. Ping булардын эч бирин кылбайт.

fail-closed далилдеп, MTUну текшериңиз

Маршруттун жоголушу өз алдынча fail-closed саясаты эмес. Башка таблица, демейки маршрут же саясат эрежеси үнсүз камдык жол бериши мүмкүн, жана муну билүүнүн бирден бир жолу — сырткы туннелди түшүрүп, колдонмо трафиги эмне кыларын байкоо. Муну кокустан табуудан көрө терезеде атайын жасаңыз.

Үч абалды текшериңиз: сырткы туннель төмөн, ички туннель төмөн жана экөө тең кайра көтөрүлгөндөн кийинки калыбына келүү. Ар бир шлюзда саясат эсептегичтерин колдонуңуз, анткени эки орнотулган IKE сессиясы башкаруу тегиздигиндеги сүйлөшүүлөрдүн ийгиликтүү болгонун гана далилдейт.

Эки инкапсуляцияны тең эсепке алыңыз. Иштеген IKE — кичине пакеттердин натыйжасы, ал эми толук өлчөмдөгү колдонмо пакеттери эки аталыш кошулгандан кийин да ийгиликсиз болушу мүмкүн; сандар кошулат деп божомолдоонун ордуна чыныгы жолдо белгилүү жүк өлчөмү менен сынаңыз. Арифметика жеңил, жол андай эмес.

Тектеш макалалар