Может ли один интерфейс WAN обслуживать и VPN между площадками, и удалённый доступ?

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

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

Две записи до любой конфигурации

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

Запись мобильного пользователя шире и личнее. Она перечисляет протокол и порт клиента, способ аутентификации пользователя или устройства, пул адресов, выдаваемый при подключении, ресурсы, доступные этому пулу, префиксы раздельного туннеля, DNS-серверы, передаваемые клиенту, и любой второй фактор. Каждое поле отвечает на вопрос о неизвестном числе пользователей, а не об одном шлюзе.

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

Где расходятся сопоставление партнёров и аутентификация

В IOS XE профиль IKEv2 несёт параметры, о которых нельзя договориться, и условия, по которым выбирается партнёр. Это значит, что стороне филиала и стороне мобильности нужен каждая свой профиль, даже когда они завершаются на одном интерфейсе и даже когда они используют одну криптографическую PKI. Cisco описывает роли профиля, аутентификации и сопоставления в своём руководстве по настройке IKEv2 для IOS XE 17.

Профиль филиала обычно сопоставляется с узкой идентичностью: удалённым адресом, FQDN или субъектом сертификата. Нечто вроде match identity remote address 198.51.100.10 255.255.255.255 закрепляет одного партнёра, а authentication remote pre-share с ключом, хранимым для каждой площадки, достаточно. Держите сопоставление настолько точным, насколько позволяет инвентарь партнёров, потому что перекрывающийся шаблон выше в порядке выбора может втянуть трафик филиала в неверный профиль.

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

Пересылка и трансляция требуют того же разделения

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

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

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

Приёмочные случаи, которые вскрывают перекрёстную политику

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

Затем подтвердите плоскость данных, а не конфигурацию. show crypto ikev2 sa и show crypto ipsec sa показывают, какой профиль и какие селекторы несли каждый поток, а show ip nat translations и счётчики туннеля показывают, действительно ли совпали обратный путь и исключение. Трассировка или захват пакетов на интерфейсе туннеля замыкает цикл.

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