Инспекция на NVA в Azure: защо отговорът минава през друг firewall

Поток от клона към 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 говорители, научава маршрутите им и ги програмира в ефективните маршрути на виртуалната мрежа. Това е задача на контролната плоскост. Той не чете таблицата на сесиите на firewall от доставчик и няма представа кой уред е допуснал дадена връзка. Два следващи хопа с еднаква цена са, за тази тъкан, просто два начина да се достигне един и същ префикс и тя ще използва който и да е.

Следователно научаването на маршрут доказва достижимост. То не доказва нищо за това дали устройството от другата страна е виждало този поток преди.

Прочетете двете посоки, преди да проектирате

Започнете, като запишете насочването, което реално имате във всяка посока, а не това, което сте възнамерявали. По-конкретните BGP маршрути, дефинираните от потребителя маршрути и поведението на шлюза се конкурират и победителят се решава за всяка дестинация, не за всяка сесия. Маршрут по подразбиране на NVA не означава, че всеки частен префикс минава през него.

Полезна проверка е да попитате за конкретен IP на работното натоварване кой следващ хоп се разрешава във всяка посока. Ако отговорът е два различни уреда, имате проблем с асиметрията, независимо дали вече се е проявила.

Къде живее състоянието

Firewall със следене на състоянието допуска връзка и пази запис в таблица с ключ по петорката. Отговорът трябва да достигне устройството, което държи този запис, или това устройство трябва да получи състоянието по друг начин. Нищо в плоскостта на данните на Azure не препраща записа между устройствата. Или трафикът се насочва обратно към собственика, или устройствата споделят състояние чрез механизъм на доставчика, или проектът не работи.

Ето защо два здрави NVA не са проверка на здравето за инспекция. Здравето е за достижимост; инспекцията е за това кой екземпляр държи сесията.

Поддържани HA модели и какво обещава всеки

Microsoft's guidance on маршрутното намерение на Virtual WAN описват ограничено поведение за свързаност с двойна роля и firewall NVA, където директното маршрутизиране може да заобикали нормалното симетрично налагане на хъба. Четете тези бележки като ограничения върху избраната топология, а не като забрана за активно-активни проекти. Доставчикска двойка, която синхронизира състояние или насочва по поток, може да бъде поддържана. Двойка с еднаква цена, която не прави нито едното, не е.

След това определете какво се случва със съществуващите сесии при отказ на възел. Конвергенцията на маршрутите възстановява достижимостта за нови потоци за секунди, докато старото състояние на firewall просто изчезва. Повторното свързване на клиента може да е документираният резултат и това е решение, което се взема преди инцидента, а не по време на него.

Какво да тествате, преди да му се доверите

Test with inspection enabled and политиката за достъп на работното натоварване на място, защото всяко от двете може да скрие асиметрията. Изпратете нов разрешен поток в двете посоки и потвърдете, че същият уред е видял и двете половини. След това пуснете продължителен трафик и задействайте одобрения отказ, като наблюдавате дали установените сесии оцеляват или се свързват отново.

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

Накрая, запишете плана като три отделни реда: собственост върху маршрутите, насочване на трафика и собственост върху състоянието на сесията. Проектите се чупят, когато първите две са решени, а третата се предполага.