ExpressRoute плюс VPN: кои домейни на отказ покривате?
Един втори тунел IPsec покрива крайна точка, а не веригата под нея. Опишете всеки домейн на отказ, после решете дали е допустим нешифрован резервен път.
Тунел IPsec, работещ през частен пиъринг на ExpressRoute, добавя шифроване към транспорт, който вече съществува. Втори тунел подобрява наличността на крайната точка и не прави абсолютно нищо за пътя на оператора под двата. Тази разлика лесно се губи, когато таблата показват два зелени тунела, а прегледът на дизайна задава друг въпрос: кои откази трябва да преживее тази връзка? Отговорете първо на това, после бройте тунелите, защото броят на зелените индикатори е свойство на слоя за шифроване, а броят на домейните на отказ е свойство на целия път.
Започнете с отказите, не със зелените тунели
Напишете четири реда, преди да начертаете каквото и да е: отказ на една крайна точка на VPN или на един партньорски екземпляр, отказ на един локален рутер или на връзка от първата миля, отказ на общия път на ExpressRoute и недостъпност на IPsec, докато частният пиъринг все още пренася трафик. Всеки ред назовава какво трябва да запази дизайнът и на всеки отговаря различен механизъм.
| Failure | What must survive | What does not cover it |
|---|---|---|
| One VPN endpoint or instance | An alternate encryption endpoint and a route to it | A second tunnel terminating on the same instance |
| One local router or first mile | Independent local equipment and transport reachability | Any number of logical tunnels |
| The ExpressRoute path | A separately designed surviving underlay | An IPsec tunnel layered on the same circuit |
| IPsec unavailable, peering up | The intended encrypted-only or approved fallback policy | Assuming the tunnel is the only route |
Microsoft документира VPN сайт-към-сайт с частни IP адреси през частен пиъринг на ExpressRoute и поддържаното съвместно съществуване с интернет-базирани връзки сайт-към-сайт. Това съвместно съществуване е различен дизайн на долния слой и не се появява просто защото сте добавили още една крайна точка на частен тунел.
Домейн на отказ 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: локалният път и операторът
Под шифроването стои физическа и търговска реалност: устройство на клиентския ръб, крос-конект, мрежа на доставчик и място за пиъринг. указанията за наличност на ExpressRoute са категорични, че излишъкът от край до край включва сегментите на клиента и на доставчика на услуги, а не само страната на Microsoft. Два логически пътя, които споделят рутер, захранване или връзка от първата миля, все още споделят тази зависимост.
Тук дизайнът обикновено се проваля при честен преглед. Две вериги от един и същ доставчик, завършващи в една и съща сграда, на оборудване от една и съща поръчка, не са два домейна на отказ. Те са един домейн на отказ с две фактури.
Задайте въпроса към оператора писмено: кои от тези пътища се разклоняват, къде и какво е документираното поведение, когато общият сегмент откаже? Устно уверение по време на разговор за дизайн не оцелява при прекъсването, за което проектирате.
Домейн на отказ 3: маршрутът, който оцелява без IPsec
Частният пиъринг и 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Сравнете научените маршрути с префиксите, които очаквахте. Резервен път, който носи малък административен товар, може да е напълно адекватен за този товар и далеч под капацитета, който производственото търсене изисква, затова запишете допускането за капацитет до маршрута.
Запишете три отделни реда, а не една присъда
Дръжте излишъка на крайната точка, излишъка на транспорта и възстановяването след бедствие като отделни записи в дизайнерския регистър, всеки със свой механизъм, своя проверка и свой собственик. Когато преглед на инцидент пита защо връзката е преживяла рестарт на шлюза, но не и прекъсване на влакно, три реда отговарят с едно изречение; една отметка „резервирано“ не може.
След това тествайте редовете, които можете да тествате евтино. Откажете един тунел и потвърдете, че трафикът се мести и се шифрова отново. Оттеглете един маршрут и потвърдете, че оцелелият път е този, който сте имали предвид, после потвърдете дали все още е шифрован. Документирайте отказите, които не можахте да симулирате, защото нетестван ред е допускане и трябва да бъде отбелязан като такова.
Полезният резултат е кратка таблица плюс изречение за всеки ред. Ако един ред няма механизъм, това е находката и е много по-евтино да я откриете при преглед на дизайна, отколкото по време на операторско прекъсване, което и двата тунела никога не биха преживели.