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

Один номер порта, два независимых правила

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

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

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

Что клиент действительно проверил

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

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

Отметьте, какое удостоверение сообщил клиент. Это имя — самая сильная подсказка о том, какая машина ответила.

Сопоставьте попытку с сервером

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

Сравните удостоверение сертификата, с которым вы столкнулись, с ожидаемым удостоверением по административному каналу. Именно это сравнение вне канала сохраняет проверку надёжной.

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

Не подгоняйте доверие под неверного собеседника

Импорт неожиданного CA заставляет симптом исчезнуть и меняет то, кому клиент доверяет. Это худшее состояние, чем неудавшееся соединение, потому что оно скрывает несоответствие вместо того, чтобы его устранить. То же относится к отключению проверки только для того, чтобы увидеть, поднимется ли туннель.

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

Сохраните текст отказа. Это единственная запись о том, что видел клиент.

После исправления проверьте новый поток

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

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

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