Шыфраваны транзіт не дае доступу да сеткі аператара

Два адабраныя шлюзы перадаюць трафік сеткі з ніжэйшым узроўнем даверу праз абмежаваную транспартную сетку. Шыфраванне карыснай нагрузкі робіць яе нечытальнай для звычайных назіральнікаў транзіту, і менавіта гэтую частку людзі праектуюць першай, а потым перастаюць пра яе думаць. Чаго шыфраванне не робіць — яно не вызначае, да якіх рэсурсаў можа дабрацца бок з ніжэйшым даверам. Праект патрабуе дзвюх межаў: адна вакол перадаванай размовы, другая вакол доступу да самога аператара.

Выконвайце прыведзеныя ніжэй крокі па парадку і ўспрымайце збой на любым кроку як змену праекта, а не як наладку канфігурацыі.

Вызначце абедзве межы, перш чым кранаць канфігурацыю

Першая мяжа — гэта размова: якія пары шлюзаў могуць устанавіць тунель і які ўнутраны трафік дапускаецца праз яго. Другая — гэта аператар: якія адрасы і сэрвісы хасты з ніжэйшым даверам могуць дасягнуць па-за тунелем. Каманды звычайна будуюць першую, а другую атрымліваюць у спадчыну ад любога існага маршрутызавання, і менавіта так абмежаваны праект ціха ператвараецца ў шырокі. Гэтая спадчына — звычайная першапрычына, калі прагляд выяўляе, што хост з ніжэйшым даверам размаўляе з чымсьці, чаго ніхто не адабраў.

Запішыце абедзве як спісы адрасоў, партоў і кірункаў. Калі спіс не атрымліваецца запісаць, мяжа яшчэ не вызначана.

Крок 1: абмяжуйце знешні тунель

На інтэрфейсе, скіраваным да аператара, дазвольце толькі тое, што патрэбна тунелю: IKE на UDP 500 і 4500 паміж двума адрасамі шлюзаў і ESP там, дзе не выкарыстоўваецца абыход NAT. Адхіляйце ўсё астатняе, што прыходзіць на гэты інтэрфейс, уключаючы пратаколы кіравання. Спецыфікацыя ESP апісвае службы абароны; яна нічога не кажа пра тое, якімі ўласнымі сэрвісамі аператара могуць карыстацца шлюзы. Выразіце гэта як яўны спіс дазволаў, каб нядаўна апублікаваны сэрвіс аператара не стаў дасягальным па змаўчанні.

Гэта набор правілаў, які робіць праект транзітным праектам, а не пагадненнем аб пірынгу.

Праверце гэта з боку з ніжэйшым даверам, а не з кансолі шлюза. Хост там павінен не мець магчымасці дасягнуць DNS-сэрвера аператара нават да ўзняцця тунеля.

Крок 2: вырашыце, што дастаўляе далёкі шлюз

На далёкім канцы адноўлены трафік павінен ісці ў пэўнае месца. Вызначце, якія ўнутраныя сэрвісы дазволеныя, з якіх дыяпазонаў крыніц і ці чакаецца сіметрычны адказ. Разгледзьце доступ да кіравання асобна, бо той жа шлюз часта адкрывае адміністрацыйны інтэрфейс, які ніколі не быў часткай транзітнага плана.

Дыяграма, якая спыняецца на паспяховым расшыфраванні, прапусціла самае важнае рашэнне.

Крок 3: захоўвайце ўладальніка для кожнага ўзроўню

Транзітнае абсталяванне ўсё яшчэ атрымлівае і перасылае знешнія пакеты, таму яму патрэбныя латкі і планаванне ёмістасці. Канцавыя пункты тунеля апрацоўваюць абаронены пратакол і адкрываюць унутраны трафік свайму шляху перасылкі, таму ім патрэбныя ўласныя правілы і ўласны маніторынг. Канцавыя праграмы апрацоўваюць карысную нагрузку, а непразрыстая нагрузка не з'яўляецца доказам таго, што расшыфраванае спампоўванне бясшкоднае.

Прызначце ўладальніка кожнаму ўзроўню. Менавіта ўзроўні без уладальніка дрыфтуюць.

Крок 4: праверце, а потым перадайце гэта ўстанове

Праверце знешні шлях, калі тунель узняты і правілы аператара на месцы. Затым паспрабуйце кожны рэсурс, да якога бок з ніжэйшым даверам не павінен дабрацца, і пераканайцеся, што збой — гэта адмова, а не тайм-аўт, які хавае маршрут. Праверце таксама даступнасць і ліміты рэсурсаў, бо нават шыфраванае злучэнне можна насыціць.

Для рэгуляваных або закрытых асяроддзяў аднясіце праект да адказнага органа бяспекі і выкарыстайце яго адабраную архітэктуру падзелу. Канфігурацыя VPN і канцэптуальнае тлумачэнне не ствараюць акрэдытацыі. Гэты крок — не паперы; ён вырашае, ці можа праект наогул існаваць.