Перевірка 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 майже нічого не каже, якщо відповідь так і не повернулася туди.

Нарешті, запишіть план трьома окремими рядками: володіння маршрутами, керування трафіком і володіння станом сесії. Проєкти ламаються, коли перші два вирішено, а третій припускають.