Ping с IPsec-шлюза использует другой адрес источника

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

Три разных вопроса, на которые может ответить ping

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

Сначала выберите вопрос. Иначе неудачный ping станет доказательством той теории, которая у вас уже была.

Почему шлюз выбирает адрес, которого вы не ожидали

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

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

Выбирайте источник осознанно

На управляемом Linux-шлюзе выберите источник, который уже назначен локально: ping -c 4 -I 10.30.0.1 10.40.0.20. Адреса здесь приведены для примера, поэтому подставьте реальный внутренний адрес шлюза и реальное удалённое назначение и убедитесь, что выбранный источник принадлежит этому устройству и допускается политикой площадки.

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

Читайте обратный путь, а не только запрос

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

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

Затем проверьте рабочую нагрузку

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

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

Не добавляйте общий маршрут для 169.254.0.0/16 только для того, чтобы получить один диагностический ответ. Это меняет вводящий в заблуждение тест на постоянное решение о маршрутизации, и следующий человек наследует его без контекста.