Беспроводной канал как резерв: маршрутизируемое переключение или один сегмент?

Решите, восстанавливает ли резерв маршрутизируемую доступность или расширяет один сегмент Ethernet. Выбор определяет управление петлями, проверки состояния и восстановление.

Два здания, радиоканал «точка-точка» и интернет-VPN, который может служить вторым путём. Прежде чем резерв станет автоматическим, один вопрос решает почти всё остальное: что должно выжить — доступность IP между отдельными подсетями или один общий сегмент Ethernet? То, что радио ведёт себя как кабель, не является аргументом передавать каждый широковещательный кадр через интернет. Сначала ответьте на вопрос, потому что два ответа требуют разного управления петлями, разных проверок состояния и разного понимания того, что значит восстановление.

Определите, что должно пережить сбой

Перечислите приложения, которые должны продолжать работать, и отметьте, зависят ли они от доступности на Layer 3 или от соседства на Layer 2. Общий доступ к файлам, подключения к базам данных и веб-службы обычно заботятся только о маршрутах; протоколы обнаружения, некоторые кластерные продукты и всё, что ожидает один широковещательный домен, заботятся о соседстве. Резерв, восстанавливающий неверный тип доступности, создаёт площадку, технически связанную и практически бесполезную.

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

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

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

ip route show | grep -E '10.44\.|10.45\.'
ip route get 10.45.0.10
ip route get 10.45.0.10 from 10.44.0.1

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

Мост-переключение: один сегмент, один блокирующий путь

Если соседство действительно необходимо, резерв должен передавать кадры Ethernet, чего маршрутизируемый туннель IP не делает. Некоторые платформы поддерживают объединение интерфейса VPN в локальный сегмент через мост, и такие интерфейсы становятся членами моста со всеми последствиями. Два одновременно пересылающих пути на Layer 2 образуют петлю, поэтому проекту нужен охватывающий оба участка связующее дерево и ясное указание, какой путь должен блокироваться.

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

Следите за границей, которая важна

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

ping -c 3 -W 2 10.45.0.10
ip -brief link show dev wlan0
ip route get 10.45.0.10

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

Отрабатывайте оба направления под нагрузкой

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

sudo ip link set dev wlan0 down
ip route get 10.45.0.10
sudo ip link set dev wlan0 up
ip route get 10.45.0.10

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

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