UDR në Azure drejt një porte VPN: një destinacion, jo i gjithë dalja

Shtoni një rrugë të përcaktuar nga përdoruesi për një prefiks të jashtëm, e drejtoni te porta VPN, dhe trafiku vazhdon të dalë përmes rrugës së internetit të Azure. Ose del saktë dhe përgjigja nuk kthehet kurrë. Të dyja rezultatet vijnë nga i njëjti gabim: trajtimi i hop-it të ardhshëm të Azure si i gjithë dizajni. Tabela e rrugëve vendos vetëm cilën dalje merr një paketë brenda Azure. Çfarë ndodh me të pas tunelit dhe si kthehet përgjigja është gjysma e dytë që duhet të ndërtoni.

Hop-i i ardhshëm është një portë, jo IP e një pajisjeje

Një UDR dërgon një prefiks përputhës te një lloj hop-i të ardhshëm, dhe VirtualNetworkGateway është lloj, jo adresë. Njerëzit ngjitin IP-në private të portës në një rrugë VirtualAppliance dhe pastaj pyesin pse asgjë nuk përputhet, sepse ai lloj pret një NIC ose një balancues të brendshëm ngarkese. Dokumentacioni i rrugëzimit të Microsoft kufizon gjithashtu hop-in e ardhshëm të portës në një rrjet virtual, porta e të cilit është portë VPN. ExpressRoute, Route Server dhe një hub Virtual WAN nuk adresohen nga ajo opsion.

Kontrolloni çfarë ka vërtet rrjeti virtual përpara se të shkruani rrugën. Nëse dizajni rrugëzon përmes një hub-i, rruga i përket pronarit të rrugëzimit të hub-it, jo degës që po redaktoni.

Lexoni rrugën efektive përpara se të ndryshoni diçka

Azure kombinon rrugët e sistemit, prefikset e mësuara nga BGP dhe UDR-të në një tabelë rrugësh efektive për çdo NIC, dhe prefiksi përputhës më i gjatë fiton pavarësisht nga erdhi. Për të njëjtin prefiks, një UDR mund një rrugë BGP. Ky rend është arsyeja pse një UDR i vjetër nga një eksperiment i mëparshëm mund të mbivendosë në heshtje prefiksin që sapo mësuat përmes tunelit.

Shikoni së pari tabelën efektive, pastaj vendosni nëse po shtoni një rrugë apo po zëvendësoni një:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

Lexoni edhe kolonën e burimit, jo vetëm prefiksin. Një rrugë me prefiksin e duhur dhe burimin e gabuar ju tregon cilin objekt të redaktoni dhe ju shpëton nga shtimi i një rruge të dytë që humbet ndaj së parës.

Shkruani rrugën sipas prefiksit dhe nënrrjetit realë

Përdorni prefiksin real të destinacionit, marrë nga shërbimi që arrini vërtet, në vend të një diapazoni publik të kopjuar nga një postim forumi. Filloni me një shërbim të miratuar përpara se të merrni parasysh një rrugë të paracaktuar që lëviz të gjithë daljen. Më pas lidhni tabelën e rrugëve me nënrrjetin e ngarkesës së punës. Nënrrjeti i portës ka kërkesat e veta, dhe lidhja e tabelës tuaj atje e prish portën në vend që të drejtojë ngarkesën.

Krijoni rrugën, pastaj lidhni tabelën me nënrrjetin që strehon ngarkesën e punës:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

Edhe përhapja ka rëndësi. Me përhapjen BGP të aktivizuar në atë tabelë, prefikset e mësuara shfaqen pranë atyre që shkruat, dhe një prefiks i mësuar më specifik mund të mundë një UDR më të gjerë. Çaktivizoni përhapjen vetëm kur dëshironi që grupi i UDR-ve të jetë autoritar për atë nënrrjet.

Përfundoni gjysmën lokale, përndryshe rrjedha vdes atje

Porta lokale duhet të pranojë burimin Azure, ta përcjellë te destinacioni dhe ta lejojë aplikacionin. Rruga e saj e mëtejshme mund të jetë një dalje interneti ose një hop tjetër privat, por ky vendim i përket planit, jo tabelës së rrugëve Azure. Dështimi i zakonshëm është kthimi. Një destinacion interneti nuk do të rrugëzojë një burim privat Azure përsëri te ju, kështu që përgjigja shkon te porta e vetë e paracaktuar dhe vdes, ose nuk del fare.

Dy dizajne e zgjidhin këtë dhe nuk janë të këmbyeshëm. Përktheni burimin në dalje, kështu që destinacioni t'i përgjigjet një adrese publike që zotëron rrjeti lokal. Ose ruani burimin dhe ndërtoni një marrëdhënie kthimi të rrugëzuar, që përgjigjet të kthehen përmes tunelit. Zgjidhni një dhe shkruani cilën adresë do të shohë aplikacioni.

Përzgjedhësit dhe listat e lejeve janë të ndara nga e gjithë kjo. Zgjedhja e një hop-i të ardhshëm Azure nuk zgjeron përzgjedhësit e trafikut VPN dhe nuk ndryshon listën e burimeve të lejuara të një shërbimi të jashtëm.

Verifikoni me burimin që vëzhgon destinacioni

Dërgoni kërkesën nga ngarkesa reale e punës dhe jo nga një host kërcimi në një nënrrjet tjetër, pastaj lexoni adresën e burimit që vëzhgoi destinacioni. Ai vlerë i vetëm ju tregon cili nga dy dizajnet e kthimit është në fuqi. Më pas kontrolloni rrugën e përgjigjes dhe konfirmoni se trafiku normal i menaxhimit drejt VM-së ende funksionon, sepse një rrugë e paracaktuar e shtuar aksidentalisht shfaqet si sesion SSH i prishur shumë përpara se të shfaqet si aplikacion i prishur.

Një transit përmes një prefiksi të zgjedhur është një ndryshim shumë më i ngushtë se tunelimi i detyruar. Mbaheni të ngushtë dhe kthimi pas është fshirja e një rruge.