DHCP-ретрансляция на ASA через VPN «сайт-сайт»: пошаговое руководство

Ретрансляция работает в три этапа, и только средний пересекает VPN. Клиент широковещательно отправляет запрос в сегменте филиала, ASA превращает эту широковещательную рассылку в одноадресный запрос к серверу DHCP, а сервер отвечает на адрес ретрансляции, а не клиента. Пройдите этапы в этом порядке, и большинство случаев «ретрансляция сломана» сводятся к отсутствующей политике или неверно прочитанной строке setroute.

Этап первый: включите ретрансляцию на интерфейсе со стороны клиентов

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

Проверьте текущую конфигурацию, прежде чем что-то менять: на каком интерфейсе включена ретрансляция, какая форма сервера присутствует и привязан ли setroute к клиентскому интерфейсу. Если ASA также работает как сервер DHCP для другого сегмента, остановитесь и прочитайте список ограничений; сервер и ретрансляцию нельзя включить одновременно на одном устройстве.

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

Этап второй: проведите трафик, создаваемый ASA, через туннель

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

Убедитесь, что интересующий трафик охватывает источник ретрансляции ASA и адрес сервера, а обратное направление тоже разрешено. В схеме на базе VTI решение о маршрутизации проще, но поддержка ретрансляции через VTI появилась в определённом выпуске; руководство ASA по DHCP указывает 9.14(1), поэтому проверьте образ, прежде чем копировать пример VTI на более старое устройство.

Ping с ASA до сервера сам по себе доказывает немногое. Он может пройти другим путём, с другого адреса источника или по политике, которой пакеты ретрансляции не соответствуют.

Этап третий: прочитайте ответ и параметр setroute

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

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

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

Что я проверяю, прежде чем сказать, что исправлено

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

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

Запишите три этапа в журнал изменений: интерфейс со стороны клиентов, политику VPN, покрывающую трафик ретрансляции, и обратный маршрут сервера к giaddr. Именно эта запись делает следующее построение филиала повторяемой работой, а не сеансом отладки. Она также говорит следующему инженеру, какой вывод команды собрать первым.