Azure NVA инспекција: зошто одговорот оди низ друг 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 воспоставува peering со поддржани BGP говорници, ги учи нивните рути и ги програмира во ефективните рути на виртуелната мрежа. Тоа е работа на контролната рамнина. Не ја чита табелата со сесии на firewall од добавувач и нема поим кој уред дозволил дадена врска. Два следни скока со еднаква цена се, за ова ткиво, едноставно два начина да се стигне истиот префикс и ќе употреби било кој.

Учењето рута затоа докажува достапност. Не докажува ништо за тоа дали уредот на другиот крај претходно го видел овој тек.

Прочитајте ги двете насоки пред да проектирате

Започнете со запишување на управувањето што навистина го имате во секоја насока, а не она што сте го намеравале. Порадикалните BGP рути, рутите дефинирани од корисникот и однесувањето на портата сите се натпреваруваат и победникот се одлучува по дестинација, а не по сесија. Стандардна рута на NVA не значи дека секој приватен префикс поминува низ неа.

Корисна проверка е да прашате, за една конкретна IP адреса на работно оптоварување, на кој следен скок се разрешува секоја насока. Ако одговорот се два различни уреда, имате проблем со асиметрија без оглед на тоа дали се појавил.

Каде живее состојбата

Firewall со состојба прифаќа врска и држи запис во табела со клуч на петорката. Одговорот мора да стигне до уредот што го држи записот или тој уред мора да ја добие состојбата на друг начин. Ништо во податочната рамнина на Azure не го проследува записот помеѓу уредите. Или сообраќајот се насочува назад кон сопственикот, или уредите делат состојба преку механизам на добавувачот, или проектот не функционира.

Затоа два здрави NVA не се здравствена проверка за инспекција. Здравјето е за достапноста; инспекцијата е за тоа која инстанца ја држи сесијата.

Поддржани HA модели и што ветува секој

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

Потоа дефинирајте што се случува со постојните сесии кога јазолот ќе откаже. Конвергенцијата на рутите ја враќа достапноста за нови текови во секунди, додека старата состојба на firewall едноставно исчезнува. Повторното поврзување на клиентот може да биде документираниот исход и тоа е одлука што се носи пред инцидентот, а не за време на него.

Што да тестирате пред да му верувате

Test with inspection enabled and политиката за пристап на работното оптоварување на место, бидејќи било кое од двете може да ја сокрие асиметријата. Испратете нов овластен тек во двете насоки и потврдете дека истиот уред ги видел двете половини. Потоа пуштете постојан сообраќај и активирајте го одобреното префрлување, набљудувајќи дали воспоставените сесии преживуваат или се поврзуваат повторно.

Поврзете го секој тек со уредот што го обработил. Фаќање пакети на еден NVA не ви кажува речиси ништо ако одговорот никогаш не се вратил таму.

Конечно, напишете го планот како три одделни реда: сопственост на рутите, насочување на сообраќајот и сопственост на состојбата на сесијата. Проектите се кршат кога првите две се решени, а третата се претпоставува.