Централизиране на партньорския VPN достъп без обединяване на партньорите

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

Започнете от договора, който всеки партньор вече е подписал

Преди каквато и да е конфигурация потвърдете, че партньорът изобщо разрешава общ шлюз или връзка към сайт. Личен акаунт за отдалечен достъп, изискване за състояние на устройството или интерактивен MFA поток може да не е преносим към общ тунел без надзор, а струпването на служители зад една копирана клиентска идентичност е онзи пряк път, който оцелява, докато партньорът не одитира своите логове. За всяка разрешена връзка запишете диапазоните на дестинация, частните домейни DNS, разрешените вътрешни източници, собственика на автентикацията и какво трябва да се случи, когато тунелът се повреди. Помолете партньора да потвърди общата връзка писмено, включително диапазоните на източника, които ще приемат. Устното одобрение обикновено сменя смисъла си в седмицата, в която се сменя екипът им по сигурност.

Този запис е резултатът. Ако не можете да го напишете за един партньор, този партньор не е готов за централизация.

Маршрутизирайте по контекст, не само по дестинация

Двама партньори в крайна сметка ще използват един и същ частен диапазон, защото всяка организация избира от същото пространство RFC 1918. Една обикновена таблица за маршрутизация не може да избере правилния партньор само по адрес на дестинация, затова припокриващите се диапазони се нуждаят от отделни контексти на маршрутизация или друг договорен дизайн. Моделът на домейн за препращане в RFC 4364 описва защо разделянето е важно, а едно внедряване не се нуждае от MPLS, за да изисква същото свойство от своята шлюзова платформа.

Попитайте платформата направо: могат ли двама партньори да споделят един префикс на дестинация и все пак да се различават по това от кой контекст на служител е дошла сесията? Ако отговорът е не, това ограничение оформя дизайна повече от всеки списък с функции на доставчик.

Където отговорът е да, контекстът на маршрутизация става това, което документирате и тествате, защото той е невидим в traceroute.

Решете какво въвежда служителят и какво записва партньорът

Част от партньорската работа пасва на прокси за приложения или отдалечено работно пространство, отворено в контекста на този партньор. Друга работа изисква маршрутизиран мрежов достъп от одобрен сегмент на служители, и двете дават различни адреси на източника и различни одиторски следи в далечния край. Общ транслатиран адрес на източника може да удовлетвори списък с разрешения, докато крие кое устройство какво е направило, затова пазете надежден запис служител-сесия и запазете автентикацията на приложението, вместо да третирате адреса на шлюза като идентичност; това е удобно точно до момента, в който партньорът попита кой го е направил.

След това преминете през една реална задача от страната на служителя: какво кликват, какво се иска от тях и какво би видял партньорът, ако поиска запис в лога. Ако това преминаване не е възпроизводимо, дизайнът не е завършен.

Забранете транзита между партньори изрично

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

Запишете забраната в партньорския запис до разрешенията, за да оцелее намерението след смени на персонала.

Пуснете го като обща услуга, а не като по-голям лаптоп

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

Приемете нивото само когато отказана междупартньорска заявка се провали точно както е предвидено и разрешена заявка на служител достигне правилната дестинация с правилния източник. Премахването на конфликта с лаптопите при запазена граница на всеки партньор е целият смисъл; дизайн, в който всеки отдалечен префикс е достъпен от всяко бюро, просто е преместил проблема.

Пазете малка таблица с партньор, контекст, разрешени диапазони и собственик. Тя ще е първото нещо, което някой ще поиска при инцидент.