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 успоставља peer однос са подржаним BGP говорницима, учи њихове руте и програмира их у ефективне руте виртуелне мреже. То је посао контролне равни. Он не чита табелу сесија firewall-а добављача и не зна који је уређај дозволио дату везу. Два следећа скока једнаке цене за ово су ткиво само два начина да се достигне исти префикс и користиће било који.

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

Прочитајте оба смера пре него што пројектујете

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

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

Где стање живи

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

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

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

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

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

Шта тестирати пре него што му верујете

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

Повежите сваки ток са уређајем који га је обрадио. Снимање пакета на једном NVA не говори готово ништа ако се одговор никада није вратио на њега.

На крају, напишите план као три одвојена реда: власништво над рутама, усмеравање саобраћаја и власништво над стањем сесије. Дизајни се ломе када су прва два решена, а треће се претпоставља.