ExpressRoute плус VPN: које домене отказа покривате?
Други IPsec тунел покрива једну крајњу тачку, а не коло испод ње. Мапирајте сваки домен отказа, затим одлучите да ли је дозвољен нешифровани резервни пут.
IPsec тунел који ради преко приватног пееринга ExpressRoute додаје шифровање транспорту који већ постоји. Други тунел побољшава доступност крајње тачке и не чини баш ништа за пут оператера испод оба. Ту разлику је лако изгубити када контролне табле приказују два зелена тунела, а преглед пројекта поставља друго питање: које отказе ова веза мора да преживи? Одговорите прво на то, па бројите тунеле, јер је број зелених индикатора својство слоја шифровања, а број домена отказа својство целог пута.
Почните од отказа, а не од зелених тунела
Напишите четири реда пре него што било шта нацртате: отказ једне VPN крајње тачке или једне peer инстанце, отказ једног локалног рутера или везе прве миље, отказ заједничког пута 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
Упоредите научене руте са префиксима које сте очекивали. Резервни пут који носи мали административни терет може бити потпуно адекватан за тај терет и далеко од капацитета који производни захтев тражи, зато запишите претпоставку о капацитету поред руте.
Забележите три одвојена реда, а не једну пресуду
Држите редундантност крајње тачке, редундантност транспорта и опоравак после катастрофе као одвојене уносе у пројектном регистру, сваки са својим механизмом, својом провером и својим власником. Када преглед инцидента пита зашто је веза преживела рестарт гејтвеја, али не и пресек влакна, три реда одговарају у једној реченици; једно поље „редундантно“ то не може.
Затим тестирајте редове које можете јефтино да тестирате. Обарајте један тунел и потврдите да се саобраћај премешта и поново шифрује. Повуците једну руту и потврдите да је преостали пут онај који сте намеравали, затим потврдите да ли је још шифрован. Документујте отказе које нисте могли да симулирате, јер неистестиран ред је претпоставка и треба тако да буде означен.
Користан резултат је кратка табела плус реченица по реду. Ако ред нема механизам, то је налаз, и много је јефтиније открити га на прегледу пројекта него током прекида оператера који ниједан од два тунела никада не би преживео.