ExpressRoute плус VPN: кои домени на откажување ги покривате?

IPsec тунел што работи преку приватниот peering на ExpressRoute додава шифрирање на транспорт што веќе постои. Вториот тунел ја подобрува достапноста на крајната точка и не прави апсолутно ништо за патеката на операторот под двете. Оваа разлика лесно се губи кога панелите покажуваат два зелени тунели, а прегледот на дизајнот поставува друго прашање: кои откажувања мора да ги преживее оваа врска? Одговорете прво на тоа, потоа броете тунели, бидејќи бројот на зелени индикатори е својство на слојот за шифрирање, а бројот на домени на откажување е својство на целата патека.

Започнете со откажувања, а не со зелени тунели

Напишете четири реда пред да нацртате нешто: откажување на една VPN крајна точка или една peer инстанца, откажување на еден локален рутер или врска од прва милја, откажување на заедничката патека на ExpressRoute и недостапност на IPsec додека приватниот peering сѐ уште пренесува сообраќај. Секој ред го именува она што дизајнот мора да го зачува, и на секој одговара различен механизам.

Microsoft документира site-to-site VPN со приватни IP адреси преку приватниот peering на ExpressRoute и поддржаната коегзистенција со site-to-site врски базирани на интернет. Таа коегзистенција е различен дизајн на долниот слој и не се појавува само затоа што додадовте уште една крајна точка на приватен тунел.

Домен на откажување 1: VPN крајната точка

Два тунели на една порта обично се active-active парови што завршуваат на истиот ресурс на страната на Azure. Тие штитат од проблем со еден тунел или инстанца и не штитат од тоа тој ресурс да стане недостапен, да се реконфигурира или да остане без капацитет. Редундантност на крајната точка значи втора поддржана крајна точка, со своја патека и своја конфигурација, плус рута што може да ја достигне.

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

az network vpn-connection show -g rg-connectivity -n vpn-to-hub   --query '{conn:connectionStatus,tunnels:tunnelConnectionStatus}'
az network vnet-gateway show -g rg-connectivity -n gw-hub   --query '{sku:sku.name,activeActive:enableBgp,peers:bgpSettings.peers}'

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

Домен на откажување 2: локалната патека и операторот

Под шифрирањето лежи физичка и комерцијална реалност: уред на раб на клиентот, вкрстено поврзување, мрежа на провајдер и локација за peering. упатствата за достапност на ExpressRoute се експлицитни дека редундантноста од крај до крај ги вклучува сегментите на клиентот и на давателот на услуги, не само страната на Microsoft. Две логички патеки што делат рутер, напојување или врска од прва милја сѐ уште ја делат таа зависност.

Тука дизајнот обично паѓа на чесен преглед. Две кола од истиот провајдер, што завршуваат во истата зграда, на опрема од истата нарачка, не се два домена на откажување. Тие се еден домен на откажување со две фактури.

Прашајте го операторот писмено: кои од овие патеки се раздвојуваат, каде, и кое е документираното однесување кога заедничкиот сегмент откажува? Вербално уверување за време на дизајн повик не го преживува прекинот за кој дизајнирате.

Домен на откажување 3: рутата што преживува без IPsec

Приватниот peering и IPsec можат да понудат конкурентни рути до истиот префикс на апликацијата. Ако заштитената рута исчезне, преживеаната директна ExpressRoute рута може сѐ уште да биде употреблива, без слојот за шифрирање што го обезбедуваше тунелот. Дали тоа е прифатливо е одлука за политика, и токму таа одлука најчесто се остава имплицитна.

Барањата за шифрирање и барањата за достапност тука можат навистина да се судрат. «Секоја преживеана рута се смета за успех» е изјава за достапност што тивко одговара на прашањето за шифрирање со «не». Запишете која победува, за кои префикси и кој ја одобрил.

az network vnet-gateway list-advertised-routes -g rg-connectivity -n gw-hub --peer 10.0.0.1
az network vnet-gateway list-learned-routes -g rg-connectivity -n gw-hub -o table

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

Запишете три одделни реда, а не една пресуда

Држете ја редундантноста на крајната точка, редундантноста на транспортот и закрепнувањето по катастрофа како одделни записи во регистрацијата на дизајнот, секој со свој механизам, своја проверка и свој сопственик. Кога преглед на инцидент прашува зошто врската преживеа рестарт на портата, но не и пресек на влакно, три реда одговараат со една реченица; едно поле «редундантно» не може.

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

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