Інспекцыя 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 не кажа амаль нічога, калі адказ так і не вярнуўся да яго.

Нарэшце, запішыце план трыма асобнымі радкамі: уладанне маршрутамі, кіраванне трафікам і ўладанне станам сесіі. Праекты ламаюцца, калі першыя два вырашаны, а трэцяе меркуецца.