Направьте подсеть филиала через интернет-выход SonicWall головного офиса

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

Начните с селектора, а не с маршрута

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

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

Добавьте политику филиала и затем защитите её порядок

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

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

Завершите путь в головном офисе

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

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

Решите, что делает группа, когда туннель падает

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

Согласуйте охват и приоритет этого маршрута с установленным выпуском и проверьте его, опустив туннель, а не доверяя метке. Группа, которая никогда не должна выходить локально, должна отказывать закрыто, тогда как группа, где доступность важнее, может законно откатиться; и то, и другое — решения, и ни одно не должно происходить по умолчанию.

Проверьте с трёх клиентов, затем чисто откатите

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

ip -4 route get 203.0.113.10
curl -sS -m 5 -o /dev/null -w "%{http_code}\n" https://example.com
traceroute -n -m 6 203.0.113.10

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

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