Шифровани транзит не даје приступ оператеру
Шифровање скрива корисни терет од посматрача транзита. Оно не даје хосту са нижим поверењем руте у мрежу оператера, DNS или приватне сервисе.
Два одобрена пролаза преносе саобраћај мреже са нижим поверењем преко ограничене транспортне мреже. Шифровање корисног терета га чини нечитљивим за обичне посматраче транзита, а то је део који људи прво дизајнирају и затим престану да о њему размишљају. Оно што шифровање не чини јесте да одреди којим ресурсима страна са нижим поверењем сме да приступи. Дизајн захтева две границе: једну око пренете конверзације и једну око приступа самом оператеру.
Изведите кораке испод редом и третирајте неуспех на било ком кораку као промену дизајна, а не као подешавање конфигурације.
Дефинишите обе границе пре него што додирнете конфигурацију
Прва граница је конверзација: који парови пролаза смеју да успоставе тунел и који унутрашњи саобраћај сме да прође кроз њега. Друга је оператер: којим адресама и сервисима hostови са нижим поверењем могу да приступе изван тунела. Тимови обично граде прву, а другу наслеђују од било ког усмеравања које је већ постојало, и тако ограничен дизајн тихо постаје широк. То наслеђивање је уобичајен корен проблема када преглед открије да host са нижим поверењем разговара са нечим што нико није одобрио.
Запишите обе као листе адреса, портова и смерова. Ако се листа не може записати, граница још није дефинисана.
Корак 1: ограничите спољашњи тунел
На интерфејсу окренутом оператеру дозволите само оно што је тунелу потребно: IKE на UDP 500 и 4500 између две адресе пролаза и ESP тамо где се NAT пролажење не користи. Одбијте све остало што стиже на тај интерфејс, укључујући управљачке протоколе. Спецификација ESP-а покрива заштитне сервисе; не говори ништа о томе које сопствене сервисе оператера пролази смеју да користе. Изразите то као експлицитну листу дозвола, како новообјављени сервис оператера не би постао доступан по подразумеваном.
То је скуп правила који дизајн чини транзитним дизајном, а не peering аранжманом.
Проверите то са стране са нижим поверењем, не из конзоле пролаза. Host тамо би требало да не успе да дође до DNS сервера оператера чак и пре него што је тунел подигнут.
Корак 2: одлучите шта удаљени пролаз испоручује
На удаљеном крају обновљени саобраћај мора да иде на одређено место. Дефинишите који су унутрашњи сервиси дозвољени, из којих распона извора и да ли се очекују симетрични одговори. Прегледајте управљачки приступ одвојено, јер исти пролаз често излаже административни интерфејс који никада није био део транзитног плана.
Дијаграм који се зауставља на успешном дешифровању прескочио је одлуку која је најважнија.
Корак 3: задржите власништво по слоју
Транзитна опрема и даље прима и прослеђује спољашње пакете, па јој требају закрпе и планирање капацитета. Крајње тачке тунела обрађују заштићени протокол и излажу унутрашњи саобраћај својој путањи прослеђивања, па им требају сопствена правила и сопствени надзор. Завршне апликације обрађују корисни терет, а непровидан терет није доказ да је дешифровано преузимање безопасно.
Доделите власника сваком слоју. Слојеви без власника су они који одлутају.
Корак 4: проверите, па предајте надлежном органу
Проверите спољашњу путању са подигнутим тунелом и правилима оператера на месту. Затим испробајте сваки ресурс коме страна са нижим поверењем не сме да приступи и потврдите да је неуспех одбијање, а не истек времена који скрива руту. Проверите и доступност и ограничења ресурса, јер се и шифрована веза може заситити.
За регулисана или класификована окружења однесите дизајн надлежном безбедносном органу и користите његову одобрену архитектуру раздвајања. VPN конфигурација и концептуално објашњење не успостављају акредитацију. Тај корак није папирологија; он одлучује сме ли дизајн уопште да постоји.