Централизуйте доступ партнёров по VPN, не объединяя самих партнёров

Предложение разумное: пять партнёрских туннелей разбросаны по дюжине ноутбуков, пять наборов версий клиента, пять скриптов для службы поддержки и один инженер, который знает, как всё это соединяется. Перевод на контролируемый уровень доступа устраняет разброс конечных точек. Одновременно он создаёт в архитектуре новый объект — общий сервис доступа, которому теперь нужна собственная модель авторизации; а сбой, который все недооценивают, — это центральное устройство со всеми включёнными туннелями, тихо превращающееся в транзитную сеть между организациями, которые никогда не соглашались быть соседями. Этот риск — проектный выбор, а не то, что оборудование делает само. Работа ниже — способ сохранить удобство, не принимая случайный побочный эффект.

Начните с договора, который каждый партнёр уже подписал

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

Эта запись и есть результат. Если вы не можете написать её для одного партнёра, этот партнёр не готов к централизации.

Маршрутизируйте по контексту, а не только по назначению

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

Задайте платформе прямой вопрос: могут ли два партнёра делить один и тот же префикс назначения и при этом различаться по тому, из контекста какого сотрудника пришла сессия? Если ответ нет, это ограничение формирует проект сильнее любого списка функций поставщика.

Там, где ответ да, контекст маршрутизации становится тем, что вы документируете и тестируете, потому что в traceroute он не виден.

Решите, что вводит сотрудник и что журналирует партнёр

Часть партнёрской работы укладывается в прокси приложения или удалённое рабочее пространство, открываемое в контексте этого партнёра. Другая работа требует маршрутизируемого сетевого доступа из одобренного сегмента сотрудников, и оба варианта дают разные адреса источника и разные следы аудита на дальнем конце. Общий транслированный адрес источника может удовлетворить список разрешений, скрывая при этом, какое устройство что сделало, поэтому сохраняйте надёжную связь сотрудника с сессией и оставляйте аутентификацию приложения, а не считайте адрес шлюза идентичностью — это удобно ровно до того момента, когда партнёр спросит, кто это сделал.

Затем пройдите одну реальную задачу со стороны сотрудника: на что он нажимает, что у него запрашивают и что увидел бы партнёр, запросив запись журнала. Если этот проход не воспроизводится, проект не закончен.

Явно запретите транзит между партнёрами

Общее оборудование не должно подразумевать общее доверие. Добавьте запрет как осознанное правило с назначенным ответственным, а не как случай отсутствующей настройки, и проверьте его в обе стороны запросом, который иначе прошёл бы. Проверка важна потому, что разрешение, которого просто нет, может восстановить следующий инженер, добавляющий маршрут для исправления несвязанной жалобы.

Запишите запрет в карточку партнёра рядом с разрешениями, чтобы замысел пережил смену персонала.

Ведите это как общий сервис, а не как большой ноутбук

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

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

Держите небольшую таблицу: партнёр, контекст, разрешённые диапазоны и ответственный. Именно её в первую очередь попросят во время инцидента.