Шифрленген транзит ташуучуга кирүү мүмкүнчүлүгүн бербейт

Эки бекитилген шлюз төмөн ишенимдүү тармактын трафигин чектелген транспорт тармагы аркылуу өткөрөт. Пайдалуу жүктү шифрлөө аны кадимки транзит байкоочулар үчүн окулбай турган бойдон сактайт жана адамдар эң оболу ушул бөлүгүн долбоорлоп, анан ал тууралуу ойлонууну токтотушат. Шифрлөө жасабаган нерсе — төмөн ишенимдүү тарап кайсы ресурстарга жете аларын аныктоо. Долбоорго эки чек керек: бири ташылып жаткан сүйлөшүүнүн айланасында, экинчиси ташуучунун өзүнө кирүүнүн айланасында.

Төмөнкү кадамдарды тартиби менен аткарыңыз жана кайсы болбосун кадамдагы ийгиликсиздикке конфигурацияны оңдоо эмес, долбоорду өзгөртүү катары мамиле кылыңыз.

Конфигурацияга тийишүүдөн мурун эки чекти тең аныктаңыз

Биринчи чек — сүйлөшүү: шлюздардын кайсы жуптары туннель түзө алат жана анын ичинен кайсы ички трафик өтө алат. Экинчиси — ташуучу: төмөн ишенимдүү хосттор туннелден сырткары кайсы даректерге жана кызматтарга жете алат. Топтор адатта биринчисин курат, экинчисин мурунтан бар болгон кандайдыр бир маршруттоодон мураска алышат, ошентип чектелген долбоор үнсүз кеңейип кетет. Ошол мурас — кароодо төмөн ишенимдүү хост эч ким бекитпеген нерсе менен сүйлөшүп жатканы аныкталганда көп кездешүүчү тамыр себеп.

Экөөнү тең даректердин, порттордун жана багыттардын тизмеси катары жазыңыз. Эгер тизмени жазуу мүмкүн болбосо, чек али аныктала элек.

1-кадам: сырткы туннелди чектеңиз

Ташуучуга караган интерфейсте туннелге керектүү нерселерди гана уруксат кылыңыз: эки шлюз дарегинин ортосунда UDP 500 жана 4500 аркылуу IKE, жана NAT өтүүсү колдонулбаган жерде ESP. Ошол интерфейске келген калган нерсенин баарын, анын ичинде башкаруу протоколдорун, четке кагыңыз. ESP спецификациясы коргоо кызматтарын камтыйт; ал шлюздар ташуучунун кайсы өз кызматтарын колдоно алары тууралуу эч нерсе айтпайт. Муну так уруксаттар тизмеси катары билдириңиз, жаңы жарыяланган ташуучу кызматы демейки боюнча жеткиликтүү болуп калбашы үчүн.

Бул долбоорду peering келишими эмес, транзиттик долбоор кылган эрежелер жыйындысы.

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

2-кадам: алыскы шлюз эмнени жеткирерин чечиңиз

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

Ийгиликтүү дешифрлөөдө токтогон диаграмма эң маанилүү чечимди өткөрүп жиберген.

3-кадам: ар бир катмар боюнча ээликти сактаңыз

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

Ар бир катмарга ээсин дайындаңыз. Ээси жок катмарлар — ошолор жылып кетет.

4-кадам: текшериңиз, анан аны органга өткөрүп бериңиз

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

Жөнгө салынуучу же жашыруун чөйрөлөр үчүн долбоорду жооптуу коопсуздук органына алып барыңыз жана анын бекитилген бөлүү архитектурасын колдонуңуз. VPN конфигурациясы жана концептуалдык түшүндүрмө аккредитацияны негиздебейт. Бул кадам кагаз иши эмес; ал долбоордун жашап турууга уруксаты бар-жогун чечет.