Групповой секрет vpnc или ваш логин: какое поле что принимает?
Профиль vpnc запрашивает ID группы, групповой секрет и логин XAuth, а люди вводят пароль учётной записи не в то поле. Сопоставьте каждое поле его роли.
Когда кто-то впервые даёт вам профиль vpnc, диалог учётных данных спрашивает четыре вещи и читается так, будто хочет один пароль. Это не так: общий групповой секрет и индивидуальный логин XAuth — разные значения с разными владельцами, а пароль учётной записи в поле группы даёт ошибку, похожую на неверный пароль, а не на неверное поле. Правильно выстроить это сопоставление — вся задача здесь. Протокол под всем этим — чужой проект миграции, поэтому ничто из этого не является аргументом строить новые туннели IKEv1.
Два секрета, два владельца, один диалог
Групповой секрет принадлежит профилю шлюза. Все, кто подключается через этот профиль, используют одно и то же значение, и именно поэтому он не может идентифицировать человека и не может быть отозван у одного ноутбука без изменения для всех остальных пользователей профиля. Имя пользователя и пароль XAuth принадлежат человеку, и шлюз проверяет их на втором этапе, когда связь IPsec уже установлена.
Именно эту двухэтапную форму люди упускают. Установление туннеля и аутентификация пользователя — разные обмены с разными входными данными, поэтому клиент, который так и не доходит до запроса учётных данных, вовсе не потерпел неудачу при входе. Читайте диалог как два столбца, а не один: значения уровня профиля слева, личные значения справа. Когда соединение не удаётся, последний заполненный вами столбец не обязательно виноват.
Сопоставляйте поля по роли, а не по подписи
vpnc называет свои директивы в документации проекта, а каждый графический интерфейс переименовывает их. Переведите роль каждого значения, и подписи перестанут иметь значение:
| Directive | What it carries | Who owns it |
|---|---|---|
| IPSec gateway | Address or hostname of the remote VPN endpoint | Operator |
| IPSec ID | Group identifier selecting the profile on that gateway | Operator |
| IPSec secret | Group preshared secret, not an account password | Profile, shared |
| Xauth username and password | Credentials for the per-user stage after the tunnel | Person |
Интерфейс, показывающий рядом с полем группы «Имя пользователя» и «Пароль», не ошибается — это те же три значения под другими именами. Ломается то, когда поле заполняют потому, что значение в него помещается. Групповой секрет, вставленный как пароль пользователя, аутентифицирует профиль и затем срывается на этапе пользователя; пароль учётной записи, вставленный как групповой секрет, срывается раньше, до любого запроса, и отправляет людей искать проблему в межсетевых экранах, хотя она живёт в текстовом поле.
Чем идентификатор группы не является
Слово «группа» подталкивает к неверному прочтению. Идентификатор группы здесь — это селектор, который говорит шлюзу, какую конфигурацию профиля применить; он ничего не говорит о членстве в каталоге, и совпадающее имя с обеих сторон остаётся случайностью, пока оператор его не подтвердит. Авторизация происходит после успешного XAuth, её определяет то, что шлюз настроен запрашивать, и ничего из этого не видно в диалоге клиента.
Та же осторожность относится к групповому секрету. Знать его — не идентичность, а круговое распространение одного секрета в команде — операционное решение с последствиями, которые клиент не может вам показать.
Разберитесь с двусмысленной инструкцией до подключения
В старых записках о передаче часто есть строка вроде «используйте выделенный публичный IP». Эта фраза может означать адрес, с которого список разрешений на той стороне ожидает приход вашего трафика, — это свойство выхода сети оператора, и оно никак не связано с конечной точкой, которую вы вводите в поле шлюза. Спросите, что из двух имеется в виду, прежде чем значение куда-либо уйдёт. Заполненное наоборот, оно отправляет каждый пакет на адрес, который никогда не отвечает, и полученный тайм-аут читается как заблокированный порт.
Запросите четыре вещи по проверенному каналу организации: какой клиент и протокол поддерживаются, какую конечную точку использовать, какую личность представит шлюз и как передаются учётные данные. Держите настоящие секреты вне скриншотов, заявок и общих заметок по устранению неполадок. Не отключайте проверки сертификатов и не вставляйте старый список шифров, чтобы иначе настроенный сервис выглядел совместимым, ведь соединение, работающее только за счёт ослабления проверки, — не то соединение, которое вас просили построить.
Держите старый профиль честным
IKEv1 устарел, и RFC 9395 — документ, на который ссылаются, когда возникает вопрос миграции. Успешное сопоставление полей не доказывает, что протоколу место в новом дизайне; оно покупает работающее соединение, пока замена запланирована, плюс письменный объём и владельца этой миграции.
Затем проверяйте по требованию, а не по диалогу. После подключения убедитесь, что интерфейс туннеля имеет ожидаемый адрес и что внутренний пункт назначения маршрутизируется через него; если исходное требование называло адрес выхода для списка разрешений, подтвердите и этот адрес, потому что это другой факт, чем поднятый туннель. Профиль, который правильно аутентифицируется и ничего не маршрутизирует, всё равно не выполнил задачу, для которой создан.