ExpressRoute plus VPN: cilat fusha dështimi mbuloni?

Një tunel IPsec që kalon mbi peeringun privat të ExpressRoute shton kriptim në një transport që ekziston tashmë. Një tunel i dytë përmirëson disponueshmërinë e pikës fundore dhe nuk bën absolutisht asgjë për rrugën e operatorit poshtë të dyjave. Ky dallim humbet lehtë kur panelet tregojnë dy tunele të gjelbër dhe rishikimi i projektimit shtron një pyetje tjetër: cilat dështime duhet të mbijetojë kjo lidhje? Përgjigjuni së pari asaj, pastaj numëroni tunelet, sepse numri i indikatorëve të gjelbër është veti e shtresës së kriptimit dhe numri i fushave të dështimit është veti e gjithë rrugës.

Filloni me dështimet, jo me tunelet e gjelbër

Shkruani katër rreshta përpara se të vizatoni çdo gjë: një pikë fundore VPN ose një instancë peer që dështon, një router lokal ose një lidhje e miljes së parë që dështon, rruga e përbashkët e ExpressRoute që dështon dhe IPsec që bëhet i padisponueshëm ndërsa peeringu privat ende transporton trafik. Çdo rresht emërton çfarë duhet të ruajë projektimi, dhe secilit i përgjigjet një mekanizëm tjetër.

Microsoft dokumenton VPN nga sajti në sajt me IP private mbi peeringun privat të ExpressRoute dhe bashkëjetesën e mbështetur me lidhjet nga sajti në sajt të bazuara në internet. Ajo bashkëjetesë është një projektim tjetër i shtresës së poshtme dhe nuk shfaqet thjesht sepse keni shtuar një pikë tjetër fundore tuneli privat.

Fusha e dështimit 1: pika fundore VPN

Dy tunele në një portë janë zakonisht çifte active-active që përfundojnë në të njëjtin burim në anën e Azure. Ato mbrojnë nga një problem i një tuneli ose një instance të vetme dhe nuk mbrojnë nga fakti që ai burim bëhet i padisponueshëm, rikonfigurohet ose mbaron kapaciteti. Teprica e pikës fundore nënkupton një pikë të dytë fundore të mbështetur, me rrugën e vet dhe konfigurimin e vet, plus një rrugë që mund ta arrijë atë.

Kontrolloni çfarë keni vendosur në të vërtetë dhe jo çfarë thotë diagrami, sepse portali i grupon këto burime në mënyra që fshehin lidhjen e tyre:

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}'

Nëse të dy tunelet tregojnë drejt një porte me një IP publike, keni tepricë të pikës fundore të një lloji të caktuar dhe të kufizuar. Kjo mund të jetë pikërisht ajo që kërkon kërkesa, dhe duhet thënë ashtu në vend që të përshkruhet si një lidhje e tepërt.

Fusha e dështimit 2: rruga lokale dhe operatori

Nën kriptimin qëndron një realitet fizik dhe komercial: një pajisje e skajit të klientit, një ndërlidhje, një rrjet ofruesi dhe një vend peeringu. udhëzimet e disponueshmërisë së ExpressRoute janë të qarta se teprica nga skaji në skaj përfshin segmentet e klientit dhe të ofruesit të shërbimit, jo vetëm anën e Microsoft. Dy rrugë logjike që ndajnë një router, një furnizim me energji ose një lidhje të miljes së parë vazhdojnë të ndajnë atë varësi.

Këtu një projektim zakonisht dështon në një rishikim të sinqertë. Dy qarqe nga i njëjti ofrues, që përfundojnë në të njëjtën ndërtesë, mbi pajisje nga e njëjta porosi blerjeje, nuk janë dy fusha dështimi. Janë një fushë dështimi me dy fatura.

Bëjini operatorit pyetjen me shkrim: cilat nga këto rrugë ndryshojnë, ku, dhe cili është sjellja e dokumentuar kur segmenti i përbashkët dështon? Një siguri gojore gjatë një telefonate projektimi nuk i mbijeton ndërprerjes për të cilën po projektoni.

Fusha e dështimit 3: rruga që mbijeton pa IPsec

Peeringu privat dhe IPsec mund të ofrojnë rrugë konkurruese drejt të njëjtit prefiks aplikacioni. Nëse rruga e mbrojtur zhduket, një rrugë e drejtpërdrejtë ExpressRoute që mbijeton mund të jetë ende e përdorshme, pa shtresën e kriptimit që ofronte tuneli. Nëse kjo është e pranueshme është një vendim politike, dhe është vendimi që më shpesh lihet i nënkuptuar.

Kërkesat e kriptimit dhe kërkesat e disponueshmërisë mund të përplasen vërtet këtu. «Çdo rrugë që mbijeton llogaritet si sukses» është një pohim disponueshmërie që i përgjigjet në heshtje pyetjes së kriptimit me «jo». Shkruani cila fiton, për cilat prefikse dhe kush e miratoi.

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

Krahasoni rrugët e mësuara me prefikset që prisnit. Një rrugë alternative që mban një ngarkesë të vogël administrative mund të jetë plotësisht e përshtatshme për atë ngarkesë dhe shumë larg kapacitetit që kërkon kërkesa e prodhimit, ndaj shënoni supozimin e kapacitetit pranë rrugës.

Shënoni tre rreshta të veçantë, jo një vendim të vetëm

Mbani tepricën e pikës fundore, tepricën e transportit dhe rikuperimin pas fatkeqësisë si zëra të veçantë në regjistrin e projektimit, secili me mekanizmin, verifikimin dhe pronarin e vet. Kur një rishikim incidenti pyet pse lidhja mbijetoi një rindezje të portës por jo një prerje fibre, tre rreshta përgjigjen në një fjali; një kuti e vetme «i tepërt» nuk mundet.

Më pas provoni rreshtat që mund t'i provoni lirë. Bëni një tunel të dështojë dhe konfirmoni që trafiku zhvendoset dhe rikriptohet. Tërhiqni një rrugë dhe konfirmoni që rruga që mbijeton është ajo që kishit ndërmend, pastaj konfirmoni nëse është ende e kriptuar. Dokumentoni dështimet që nuk mund t'i simulonit, sepse një rresht i paprovuar është supozim dhe duhet etiketuar si i tillë.

Rezultati i dobishëm është një tabelë e shkurtër plus një fjali për rresht. Nëse një rresht nuk ka mekanizëm, ky është gjetja, dhe është shumë më lirë ta zbulosh në një rishikim projektimi sesa gjatë një ndërprerjeje të operatorit që asnjë nga dy tunelet nuk do ta kishte mbijetuar.