Drejtimi i trafikut midis dy degëve përmes një portali VPN të Azure
Dy lidhje Site-to-Site në një portal VPN të Azure mund të kalojnë trafikun e degëve, por vetëm kur të dy skajet mësojnë prefiksin dhe ekziston rruga e kthimit në LAN.
Dy degë mund të shkëmbejnë trafik përmes një portali VPN të Azure pa asnjë tunel të drejtpërdrejtë midis tyre. Secila degë hap një lidhje Site-to-Site drejt të njëjtit portal, dhe portali përcjell prefikset e mësuara midis dy lidhjeve. Ajo që e bën këtë të funksionojë nuk është tuneli i dytë, por shkëmbimi i rrugëve: dega A duhet të mësojë prefiksin e degës B, dhe B atë të A. Kaloni nëpër kontrollet më poshtë me radhë dhe ndaloni në të parën që dështon, sepse çdo hap pasues varet prej saj.
Parakushtet, përpara se të konfiguroni çdo gjë
Katër kushte vendosin nëse ky dizajn mund të funksionojë fare. Portali duhet të jetë i bazuar në rrugë dhe në një SKU që mbështet BGP, të dyja lidhjet duhet të kenë BGP të aktivizuar, hapësirat e adresave të degëve nuk duhet të mbivendosen, dhe asnjëra palë nuk mund të mbështetet te NAT për të fshehur prefiksin e saj real.
Planifikoni ASN-të me qëllim. Vlera e paracaktuar e dokumentuar e Azure është 65515, dhe çdo ruter dege ka nevojë për ASN-në e vet private që nuk përplaset me portalin ose me degën tjetër. Ripërdorimi i një vlere të paracaktuar pa kontrolluar një konfigurim ekzistues të portalit është mënyra se si një rrugë AS refuzohet më vonë.
Konfirmoni gjithashtu se nuk po prisni sjellje të peering-ut të VNet. Portali shkëmben rrugë midis dy lidhjeve që keni konfiguruar; ai nuk i bën peering-ët arbitrarë kalimtarë. Nëse një rrjet i tretë duhet të arrijë të dyja degët, ai ka nevojë për lidhjen e vet ose rrugën e vet, jo supozimin se portali do ta shpërndajë trafikun. Shkruani këtë kufi përpara dritares së parë të ndryshimit, sepse është vendimi i dizajnit të cilit njerëzit i kthehen kur më vonë shtohet një vend i ri.
Konfiguroni në këtë rend
Çdo hap ka një rezultat të vëzhgueshëm, prandaj mos vazhdoni derisa ai të shfaqet.
- Aktivizoni BGP në portalin e rrjetit virtual dhe shënoni ASN-në dhe adresën e peer-it.
- Krijoni një portal rrjeti lokal për çdo degë me hapësirën reale të adresave të asaj dege, ASN-në e saj dhe adresën e peer-it BGP.
- Krijoni çdo lidhje Site-to-Site dhe aktivizoni BGP në vetë lidhjen.
- Konfiguroni ruterin e degës që të bëjë peering me adresën e portalit që caktoi Azure, jo me pikën fundore publike IKE të portalit sipas supozimit.
Hapi i katërt është vendi ku ngecin shumica e përpjekjeve. Adresa e peer-it BGP që raporton Azure është ajo që rutori i degës duhet të përdorë si fqinj, dhe nuk është gjithmonë adresa që njerëzit presin nga diagrami i tunelit.
Shpallni vetë prefiksin e degës, për shembull 10.10.0.0/16 nga A dhe 10.20.0.0/16 nga B. Mos shpallni një rrugë të paracaktuar ose një agregat të gjerë për të mbuluar një rrjet specifik që mungon; boshllëku kthehet më vonë si një vrimë e zezë e heshtur.
Verifikoni shkëmbimin e rrugëve në të dy skajet
Statusi i lidhjes nuk është kontrolli. IPsec mund të jetë aktiv në të dyja lidhjet ndërsa asnjë prefiks nuk kalon midis tyre. Lexoni peer-ët BGP të portalit dhe rrugët e mësuara, pastaj konfirmoni se rruga drejt degës tjetër shfaqet si një rrugë e përdorshme.
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
Një prefiks i pranishëm në një tabelë BGP mund të humbasë vendimin e përcjelljes ndaj një rruge statike ose një prefiksi më specifik. Kontrolloni rrugën e zgjedhur, jo vetëm atë të marrë.
Ndiqni rrugën e kthimit në anën e LAN
Kjo është pjesa që duket e saktë në Azure dhe dështon në vend. Një host në degën A e dërgon paketën e tij te rutori VPN i A vetëm nëse ai ruter është porta e tij e paracaktuar, ose nëse hosti ose porta e tij ka një rrugë për prefiksin e B. E njëjta gjë duhet të jetë e vërtetë edhe në drejtimin tjetër.
Nëse një ndërprerës bërthamë i veçantë është porta e paracaktuar e LAN, ai ka nevojë për rrugën drejt degës tjetër që tregon te rutori VPN. Pa të, kërkesa mbërrin dhe përgjigjja del nëpër rrugën e internetit, dhe përdoruesi sheh një lidhje që hapet dhe pastaj varet.
Mos u mbështetni te një grup sigurie rrjeti në nënrrjetin e portalit për ta rregulluar këtë. Ai nënrrjet ka kërkesat e veta dhe një NSG atje nuk është zëvendësues i mbështetur për politikën e anës së degës. Filtrimi i takon mureve të zjarrit të degëve dhe vetë ngarkesave të punës, ku rregullat mund të rishikohen nga pronarët e tyre. Zhvendosja e këtyre rregullave në një NSG nënrrjeti i fsheh ato edhe nga ekipi që do të korrigjojë dështimin tjetër.
Lejoni operacionin, pastaj provojeni me një test të refuzuar
Një rrugë e mësuar nuk është leje. Lejoni burimin, destinacionin dhe shërbimin që ju nevojiten vërtet përmes mureve të zjarrit të degëve dhe politikës së pikës fundore, dhe lini pjesën tjetër të refuzuar.
Testoni nga një ngarkesë pune e zakonshme në degën A drejt një shërbimi real në degën B, konfirmoni përgjigjjen, pastaj provoni një operacion që duhet të mbetet i ndaluar. Trafiku i gjeneruar nga vetë pajisja VPN mund të përdorë një adresë tjetër burimi dhe të kapërcejë fazën e drejtimit të LAN, pra një ping i suksesshëm nga rutori provon më pak sesa duket.
Përfundoni duke shkruar katër fakte: prefikset e shkëmbyera, ASN-të e përdorura, rrugën e kthimit LAN për secilën anë dhe politikën që lejon shërbimin. Nëse mungon njëri prej tyre, konfigurimi funksionon deri në ndryshimin e parë, dhe pastaj askush nuk mund të shpjegojë përse.