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

Сначала доберитесь до слушателя

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

Тайм-аут, отказ сертификата и отклонённая учётная запись — три разные неисправности с тремя разными проверками. Именно их первичное разделение не позволяет искать сетевую проблему как проблему учётных данных.

Докажите партнёра, затем выведите ключи

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

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

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

Три протокола, три разговора

В развёртывании OpenVPN на базе TLS управляющий канал согласует параметры безопасности, а канал данных несёт трафик туннеля, поэтому опция канала данных и проблема сертификата находятся в разных местах. IKEv2 аутентифицирует обе стороны, а затем устанавливает ассоциации безопасности IPsec со своими сроками жизни. WireGuard выводит ключи через свой обмен на основе Noise и намеренно держит машину состояний маленькой. Знание того, какой из трёх вы запускаете, определяет, какой журнал стоит читать.

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

Чего рукопожатие не делает

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

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

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

ip -brief address show tun0
ip route get 10.60.7.15
resolvectl query intranet.corp.internal

Похожие статьи