Шифрованият транзит не дава достъп до оператора

Два одобрени шлюза пренасят трафика на мрежа с по-ниско доверие през ограничена транспортна мрежа. Шифроването на полезния товар го прави нечетим за обикновените наблюдатели на транзита и точно тази част хората проектират първо, а после спират да мислят за нея. Това, което шифроването не прави, е да определя кои ресурси може да достигне страната с по-ниско доверие. Проектът се нуждае от две граници: една около пренасяния разговор и една около достъпа до самия оператор.

Изпълнете стъпките по-долу по ред и третирайте всеки отказ на която и да е стъпка като промяна в проекта, а не като настройка на конфигурацията.

Определете двете граници, преди да пипате конфигурация

Първата граница е разговорът: кои двойки шлюзове могат да установят тунел и кой вътрешен трафик се допуска през него. Втората е операторът: кои адреси и услуги хостовете с по-ниско доверие могат да достигнат извън тунела. Екипите обикновено изграждат първата и наследяват втората от каквото маршрутизиране вече е съществувало и така ограничен проект тихо се превръща в широк. Това наследяване е обичайната първопричина, когато преглед открие хост с по-ниско доверие да говори с нещо, което никой не е одобрил.

Запишете и двете като списъци от адреси, портове и посоки. Ако списък не може да бъде записан, границата още не е определена.

Стъпка 1: ограничете външния тунел

На интерфейса, обърнат към оператора, разрешете само това, което тунелът изисква: IKE на UDP 500 и 4500 между двата адреса на шлюзовете и ESP там, където не се използва обхождане на NAT. Отхвърляйте всичко останало, пристигащо на този интерфейс, включително протоколите за управление. Спецификацията на ESP обхваща услугите за защита; тя не казва нищо за това кои собствени услуги на оператора могат да използват шлюзовете. Изразете го като явен списък за разрешаване, така че новопубликувана услуга на оператора да не става достъпна по подразбиране.

Това е наборът от правила, който прави проекта транзитен проект, а не споразумение за пиъринг.

Проверете го от страната с по-ниско доверие, а не от конзолата на шлюза. Хост там трябва да не може да достигне DNS сървър на оператора дори преди тунелът да е установен.

Стъпка 2: решете какво доставя далечният шлюз

В далечния край възстановеният трафик трябва да отиде на конкретно място. Определете кои вътрешни услуги са разрешени, от кои диапазони на източника и дали се очаква отговорите да бъдат симетрични. Прегледайте административния достъп отделно, защото същият шлюз често излага административен интерфейс, който никога не е бил част от транзитния план.

Диаграма, която спира при успешното дешифриране, е пропуснала решението, което е най-важно.

Стъпка 3: запазете собственост по слоеве

Транзитното оборудване все още получава и препраща външни пакети, затова се нуждае от кръпки и планиране на капацитета. Крайните точки на тунела обработват защитения протокол и излагат вътрешния трафик на своя път за препращане, затова се нуждаят от собствени правила и собствен мониторинг. Крайните приложения обработват полезния товар и непрозрачният товар не е доказателство, че дешифрираното изтегляне е безвредно.

Назначете собственик на всеки слой. Слоевете без собственик са тези, които се разминават.

Стъпка 4: проверете, после го предайте на органа

Проверете външния път с вдигнат тунел и правила на оператора на място. След това опитайте всеки ресурс, който страната с по-ниско доверие не бива да достига, и потвърдете, че отказът е отказ, а не изчакване, което скрива маршрут. Проверете също наличността и лимитите на ресурсите, защото дори криптирана връзка може да бъде наситена.

За регулирани или класифицирани среди занесете проекта при отговорния орган по сигурност и използвайте одобрената му архитектура за разделяне. Конфигурация на VPN и концептуално обяснение не установяват акредитация. Тази стъпка не е документация; тя решава дали проектът изобщо е позволен.