Проверка NVA в Azure: почему ответ идёт через другой межсетевой экран

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

Request: branch -> VPN gateway -> NVA A -> workload
Reply:   workload -> NVA B -> VPN gateway -> branch

Этот разрыв — вся тема здесь: сходимость маршрутизации и владение состоянием сессии — разные проблемы, которые на схеме выглядят одинаково.

Что на самом деле программирует Route Server

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

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

Прочитайте оба направления до проектирования

Начните с того, что запишете управление, которое у вас реально есть в каждом направлении, а не то, которое вы задумали. Более конкретные маршруты BGP, определяемые пользователем маршруты и поведение шлюза конкурируют, и победитель определяется для каждого назначения, а не для каждой сессии. Маршрут по умолчанию на NVA не означает, что каждый частный префикс проходит через него.

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

Где живёт состояние

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

Поэтому два здоровых NVA — не проверка здоровья для инспекции. Здоровье — это достижимость; инспекция — это то, какой экземпляр владеет сессией.

Поддерживаемые модели HA и что каждая обещает

Microsoft's guidance on намерению маршрутизации Virtual WAN описывает ограниченное поведение для подключения с двойной ролью и NVA межсетевых экранов, где прямая маршрутизация может обходить обычное симметричное принуждение концентратора. Читайте эти заметки как ограничения на выбранную топологию, а не как запрет актив-активных проектов. Пара вендора, синхронизирующая состояние или направляющая по потоку, может поддерживаться. Пара равной стоимости, не делающая ни того, ни другого, — нет.

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

Что проверить, прежде чем доверять

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

Сопоставляйте каждый поток с устройством, которое его обработало. Захват пакетов на одном NVA почти ничего не говорит, если ответ так и не вернулся туда.

Наконец, запишите план тремя отдельными строками: владение маршрутами, управление трафиком и владение состоянием сессии. Проекты ломаются, когда первые две решены, а третья предполагается.