Шифрланған транзит тасымалдаушыға қатынауды бермейді

Екі мақұлданған шлюз төмен сенімді желінің трафигін шектеулі көлік желісі арқылы тасымалдайды. Пайдалы жүктемені шифрлау оны қарапайым транзит бақылаушылары үшін оқылмайтын күйде ұстайды және адамдар ең алдымен осы бөлікті жобалап, содан кейін ол туралы ойлауды қояды. Шифрлау жасамайтын нәрсе — төмен сенімді тараптың қандай ресурстарға жете алатынын анықтау. Жобаға екі шекара қажет: біреуі тасымалданатын әңгіменің айналасында, екіншісі тасымалдаушының өзіне қатынаудың айналасында.

Төмендегі қадамдарды ретімен орындаңыз және кез келген қадамдағы сәтсіздікті конфигурацияны түзету емес, жобаны өзгерту деп қарастырыңыз.

Конфигурацияға қол тигізбес бұрын екі шекараны да анықтаңыз

Бірінші шекара — әңгіме: шлюздердің қандай жұптары туннель құра алады және оның ішінен қандай ішкі трафик өте алады. Екіншісі — тасымалдаушы: төмен сенімді хосттар туннельден тыс қандай мекенжайларға және қызметтерге жете алады. Топтар әдетте біріншісін салады, ал екіншісін бұрыннан бар кез келген маршруттаудан мұраға алады, осылайша шектелген жоба үнсіз кеңейеді. Бұл мұра — шолу төмен сенімді хосттың ешкім мақұлдамаған нәрсемен сөйлесіп жатқанын анықтағанда жиі кездесетін түбірлі себеп.

Екеуін де мекенжайлар, порттар және бағыттар тізімі ретінде жазыңыз. Егер тізімді жазу мүмкін болмаса, шекара әлі анықталмаған.

1-қадам: сыртқы туннельді шектеңіз

Тасымалдаушыға қарайтын интерфейсте туннельге қажет нәрсені ғана рұқсат етіңіз: екі шлюз мекенжайы арасында UDP 500 және 4500 арқылы IKE, және NAT өтуі пайдаланылмайтын жерде ESP. Осы интерфейске келетін қалғанның бәрін, соның ішінде басқару протоколдарын қабылдамаңыз. ESP сипаттамасы қорғау қызметтерін қамтиды; ол шлюздердің тасымалдаушының қандай өз қызметтерін пайдалана алатыны туралы ештеңе айтпайды. Мұны нақты рұқсаттар тізімі ретінде көрсетіңіз, осылайша жаңа жарияланған тасымалдаушы қызметі әдепкі бойынша қолжетімді болмайды.

Бұл жобаны peering келісімі емес, транзиттік жобаға айналдыратын ережелер жиынтығы.

Оны шлюз консолінен емес, төмен сенімді жақтан тексеріңіз. Ондағы хост туннель көтерілмей тұрып-ақ тасымалдаушының DNS серверіне жете алмауы керек.

2-қадам: алыс шлюздің нені жеткізетінін шешіңіз

Алыс шетінде қалпына келтірілген трафик нақты бір жерге баруы керек. Қандай ішкі қызметтерге рұқсат етілгенін, қандай көз диапазондарынан және жауаптардың симметриялы болуы күтілетінін анықтаңыз. Басқару қатынауын бөлек қарап шығыңыз, өйткені сол шлюз жиі транзит жоспарының бөлігі болмаған әкімшілік интерфейсті ашады.

Сәтті дешифрлеуде тоқтайтын диаграмма ең маңызды шешімді өткізіп алған.

3-қадам: әр қабат бойынша меншікті сақтаңыз

Транзит жабдығы сыртқы пакеттерді әлі де қабылдап, жібереді, сондықтан оған патчтар мен сыйымдылықты жоспарлау қажет. Туннельдің соңғы нүктелері қорғалған протоколды өңдеп, ішкі трафикті өз жіберу жолына ашады, сондықтан оларға өз ережелері мен өз мониторингі қажет. Соңғы қосымшалар пайдалы жүктемені өңдейді, ал мөлдір емес жүктеме дешифрленген жүктеудің зиянсыз екеніне дәлел емес.

Әр қабатқа иесін тағайындаңыз. Иесі жоқ қабаттар — солар ауытқиды.

4-қадам: тексеріңіз, содан кейін оны органға тапсырыңыз

Сыртқы жолды туннель көтерілген және тасымалдаушы ережелері орнында болған кезде тексеріңіз. Содан кейін төмен сенімді тарап жетпеуі тиіс әрбір ресурсты сынап көріңіз және сәтсіздік бас тарту екенін, маршрутты жасыратын уақыт аяқталуы еместігін растаңыз. Қолжетімділік пен ресурс шектеулерін де тексеріңіз, өйткені шифрланған қосылым да қанық болуы мүмкін.

Реттелетін немесе құпия орталар үшін жобаны жауапты қауіпсіздік органына апарып, оның мақұлданған бөлу архитектурасын пайдаланыңыз. VPN конфигурациясы мен тұжырымдамалық түсініктеме аккредиттеу орнатпайды. Бұл қадам қағаз жұмысы емес; ол жобаның жалпы өмір сүруіне рұқсат бар-жоғын шешеді.