vpnc против Check Point или Nortel: почему он зависает

Симптом легко прочитать неправильно: vpnc запускается, спрашивает пароль группы, а затем застревает на шаге согласования, пока не сообщит, что от цели нет ответа. В выводе нигде не упоминается продукт шлюза, а учётная запись работает из браузера, поэтому очевидный вывод — неверный пароль или заблокированный порт. В большинстве таких случаев шлюз вовсе не является партнёром IPsec, поэтому обмен никогда не доходит до проверки учётных данных. Эту закономерность стоит проверить, прежде чем менять что-либо ещё в профиле.

Определите продукт, прежде чем редактировать другое поле профиля.

Сбой выглядит как неверные учётные данные

vpnc начинает с отправки IKE на UDP 500 и, если предлагается обход NAT, на UDP 4500. Шлюз, который завершает SSL вместо IPsec, не отвечает ни на то, ни на другое, поэтому клиент повторяет попытку и в конце концов сдаётся с общей ошибкой. Если та же учётная запись работает через портал в браузере, который загружает небольшое вспомогательное приложение, это сильный признак того, что туннель основан на SSL и клиент задаёт неправильный вопрос.

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

Проверьте, какой протокол предлагает шлюз

Две минуты проверки отделяют партнёра IPsec от портала SSL. Запустите их из той же сети, которую будет использовать клиент, и читайте, какие порты отвечают, а не какие указаны в документе. Сохраните результат, потому что именно эти порты решают, какой клиент должен поддерживать владелец шлюза. Проверяйте из клиентской сети, а не с хоста рядом со шлюзом.

nc -zvu gw.example.com 500
nc -zvu gw.example.com 4500
nc -zvt gw.example.com 443
curl -sI https://gw.example.com/ | head -5
openssl s_client -connect gw.example.com:443 -servername gw.example.com </dev/null | head -20

Открытый 443 с перенаправлением на страницу входа и тишина на 500 и 4500 указывают на SSL VPN. Открытые 500 и 4500 с сертификатом, отдаваемым на 443, говорят о шлюзе IPsec, который также запускает веб-интерфейс, и именно для этого случая создавался vpnc.

SSL Network Extender от Check Point и клиент Aventail от Nortel относятся ко второй категории, и ни один из них не принимает групповой секрет IKEv1.

Что профиль vpnc может и чего не может выразить

Под капотом vpnc выполняет IKEv1 с групповым предварительно общим ключом, а затем отправляет учётные данные отдельного пользователя через XAuth. Всё в его файле конфигурации относится к этому обмену: шлюз, имя группы, групповой секрет, имя пользователя и пароль пользователя. Эти поля описывают один протокол, и никакая их комбинация не заставит клиент говорить на другом.

Поэтому расширение списка шифров или отключение проверок сертификатов никогда не исправляет такой тип сбоя. Эти изменения ослабляют согласование, которого шлюз не слушает.

Выбор клиента, соответствующего шлюзу

Для шлюза Check Point используйте пакет SNX, собранный для этой версии шлюза, который поставщик публикует вместе с документацией по удалённому доступу. Старые сборки SNX часто не работают на текущих дистрибутивах, потому что ожидают 32-bit библиотеки, которые больше не установлены, а латание заброшенного пакета обычно хуже запуска поддерживаемого клиента на поддерживаемой платформе.

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

Спросите владельца шлюза о продукте и версии, о клиенте, который поддерживается в Linux, и о том, существует ли вообще профиль IPsec. Если он есть, запросите идентификатор группы и групповой секрет как отдельные пункты, потому что это не пароль пользователя, а перепутанная пара — другая частая причина неудачного туннеля. Когда соединение наконец заработает, запишите, какой протокол был согласован, чтобы следующий человек начинал с факта, а не повторял то же предположение.