Нарисуйте расшифрованный путь: где VPN-устройство применяет политику
Схема, которая заканчивается на зашифрованном слушателе, не показывает политику, которая имеет значение. Нарисуйте путь после расшифровки и сравните размещения по тому, что запрос пересекает.
Схемы поставщиков обычно заканчиваются на зашифрованном слушателе, потому что именно у этой части есть публичный адрес. Вопрос, определяющий состояние безопасности, — что происходит после расшифровки, когда пакет становится обычным IP и может достичь всего, что разрешает таблица маршрутизации. Если этот участок никто не нарисовал, у него нет владельца. Инструкция ниже сначала рисует его, а затем сравнивает размещения по тому, что расшифрованный запрос действительно пересекает.
Рисуйте пакет после расшифровки, а не до неё
Внешний путь — это часть, которую документируют поставщики: публичная конечная точка, транспортная политика, допускающая соединение, и служба, которая его завершает. Внутренний путь начинается в момент, когда пакет теряет заголовок туннеля, и дальше им управляют правила маршрутизации и фильтрации, не имеющие к туннелю никакого отношения. Поместите оба на одну страницу, потому что схема только с первым подразумевает, что допуск и авторизация — одно решение. Это не так, и именно разрыв между ними — место, где большинство размещений ошибается.
Опишите внутренний участок как нумерованную последовательность с названными типами устройств, а не как стрелку. Стрелка скрывает, пересекает ли запрос фильтр, а пересечение или его отсутствие — это весь вопрос. Каждый шаг ниже называет устройство и набор правил, действующий там, поэтому отсутствующий фильтр выглядит как пробел, а не как нечто, подразумеваемое линией.
- Удалённый клиент: устройство пользователя, создающее туннель.
- Политика на границе: набор правил, допускающий внешний транспорт к публичному слушателю.
- Терминирующее устройство: конечная точка VPN, которая декапсулирует пакет и передаёт его обычному IP.
- Внутренний фильтр: набор правил пересылки или групп безопасности, ограничивающий трафик от клиента к службе.
- Хост приложения: служба, принимающая расшифрованный запрос.
Две политики, два владельца
Внешняя политика отвечает, кто может установить туннель, и выражается в правилах, допускающих транспорт к терминирующей службе. Внутренняя политика отвечает, к какой службе может добраться аутентифицированный пользователь, и живёт в правилах пересылки, группах безопасности или самом приложении. Одно устройство может вмещать обе, и проект с несколькими устройствами тоже имеет обе. Именно раздельное именование позволяет сказать, какая из них отказала, когда пользователь не достигает приложения.
Контроли допуска, такие как сертификаты и многофакторная аутентификация, отвечают на вопрос об идентичности и ни на что больше. Они не определяют размещение и не дают разрешений по ресурсам после того, как пользователь оказался внутри.
Размещение определяет, какую границу пересекает запрос
Три размещения распространены, и каждое меняет то, какую границу пересекает расшифрованный запрос. Сравните их по тому, что там завершается, что может видеть открытый текст, какой контроль ещё может отклонить запрос и что отказывает вместе с устройством. Таблица ниже использует эти четыре столбца вместо общего вопроса, потому что каждый ответ — отдельное проектное решение.
| Placement | What terminates there | What sees plaintext | Which control can still deny | Failure domain |
|---|---|---|---|---|
| Termination in a dedicated segment | A dedicated VPN endpoint | The endpoint and anything on its segment | The filter between that segment and the application | The segment path can bypass the filter if no rule sits on it |
| Termination on the edge firewall | The firewall's public listener | The firewall, after decapsulation | The firewall's inner rule set | Admission and inspection fail together |
| Termination on the protected LAN | The appliance's LAN leg | Every host on the protected LAN | Only a host control or a downstream gateway | The appliance and the protected hosts fail together |
Третье размещение — то, которое тихо убирает применение, потому что участок на защищённом сегменте даёт устройству прямой путь, который схема может не показывать. Изучайте интерфейсы и маршруты, а не картинку: ip route get 10.20.5.10 сообщает, через какой интерфейс пакет уйдёт, и ответ часто не тот, который предполагал проект. Классическая роль межсетевого экрана по контролю трафика между состояниями, как описано вNIST SP 800-41, здесь полезная проверка, потому что устройство с неограниченным участком к защищённой сети мало что контролирует. Поиск маршрута — более честная схема, чем та, что в презентации.
Администрирование принадлежит своему собственному явно разрешённому пути. Разрешение пользователям достигать приложения никогда не требует разрешать им достигать интерфейса управления устройством, и оба разрешения следует выдавать разными правилами. Проверяйте оба пути отдельно, потому что общее правило скрывает, какой из них открыт.
Трансляция меняет то, что видят нижестоящие правила
Трансляция источника удобна и уничтожает информацию. После masquerade каждый клиент выглядит как устройство, поэтому нижестоящее правило, написанное для различения пользователей, больше не может этого делать. Это не только проблема журналов, это проблема политики: правило, привязанное к адресу клиента, тихо становится правилом, привязанным к шлюзу. Если политика по пользователям важна, сохраняйте источник или применяйте политику до трансляции.
Путь ответа заслуживает такой же проверки. Запишите, какой маршрут выбирает назначение для обратного пакета, потому что асимметричный возврат обходит проверку с учётом состояния и даёт соединение, которое устанавливается и затем застревает. Оба направления должны пересекать нарисованную границу, иначе граница — украшение.
sudo tcpdump -ni inside0 host 10.20.5.10
ip route get 10.20.5.10
sudo iptables -t nat -S POSTROUTINGПримите одну разрешённую и одну запрещённую операцию
Проверяйте с настоящего удалённого клиента, а не с хоста управления, потому что хост управления обычно находится там, где пользователь никогда не будет. Одна разрешённая операция доказывает, что путь работает, а одна запрещённая доказывает, что политика вообще что-то делает. Выполняйте обе после каждого изменения размещения и записывайте использованные идентичность источника и назначение. Проверка, доказывающая только успех, не отличает правильное правило от отсутствующего.
Затем проверьте случаи, меняющие состояние: переподключение, сеанс, переживающий ротацию ключей, и отказ самого устройства. Сравнивайте обновления, ёмкость и восстановление как часть одной компоновки, потому что одно устройство, несущее несколько логических контролей, — один домен отказа с несколькими ярлыками. Второй блок тоже не независим, когда общие административные учётные данные или неограниченный маршрут побеждают границу, которую он должен был создать.
Задокументируйте конечную точку, расшифрованный путь и контроль, который его ограничивает. Эти три строки остаются значимыми, как бы ни называлась реализация.