A ka nevojë një Azure VNet i lidhur me peering për portën e vet VPN?

Shfaqet një VNet spoke e re, hub-i ka tashmë një portë site-to-site funksionale, dhe pyetja e dukshme është nëse duhet të paguani për një portë të dytë. Zakonisht jo: transit i portës lejon spoke-in të përdorë portën e hub-it përmes peering. Tre kushte vendosin nëse kjo do të funksionojë, dhe asnjëri prej tyre nuk shihet në shenjën e statusit të peering. Lidhshmëria e peering dhe leja për të përdorur portën e dikujt tjetër janë cilësime të veçanta, prandaj dy VM që tashmë mund të pingojnë njëri-tjetrin nuk provojnë asgjë për rrugën VPN.

Kushti i parë: porta dhe mungesa e saj në spoke

Azure mbështet transit të portës për SKU-të e VPN Gateway përveç Basic, dhe mund ta mbajnë si peering rajonal ashtu edhe ai global. Spoke konsumon një portë që nuk e zotëron, prandaj nuk mund të ketë një të vetën: nëse në spoke ekziston tashmë një portë ose është zgjedhur tashmë një opsion portë e largët, cilësimi i transit që dëshironi do të jetë i padisponueshëm ose i pafuqishëm. Kontrollojeni këtë përpara se të korrigjoni çdo gjë, sepse kutia e çaktivizuar është simptoma, jo defekti. Lexoni së pari SKU-në dhe portën ekzistuese, pastaj shikoni cilësimet e peering.

Mos fshini një portë spoke ekzistuese për të shfaqur opsionin derisa të dini se çfarë varet prej saj. Rendi i migrimit është më i rëndësishëm se kutia e kontrollit.

Kushti i dytë: një cilësim në çdo drejtim peering

Peering janë dy objekte, një në çdo VNet, dhe cilësimet e transit jetojnë në anë të ndryshme të atij çifti. Peering i hub-it drejt spoke duhet t'i lejojë portës së hub-it të shërbejë spoke-in; peering i spoke drejt hub-it duhet të pranojë portën e hub-it. udhëzuesi i Microsoft për transit të portës i emërton sipas drejtimit, dhe ky është i vetmi mënyrë për t'i mbajtur të saktë:

Një kontroll i etiketuar remote ndryshon kuptimin në varësi të peering të cilit VNet po redaktoni, prandaj lexoni drejtimin, jo fjalën. Vendosni të dyja anët, ruani dhe konfirmoni që peering raporton lidhje në të dyja vendet.

Kushti i tretë: hapësira e adresave dhe kufijtë e lejeve

Transit nuk mund ta bëjë të njëjtin prefiks destinacioni të nënkuptojë dy rrjete, prandaj intervalet e hub-it, të spoke dhe të rrjetit lokal duhet të jenë të ndara përpara se ndonjë prej këtyre të funksionojë. VNet-të mund të jenë gjithashtu në abonime ose qiradhënës të ndryshëm; kjo nuk është ndalim, por identiteti që krijon ose përditëson çdo peering ka nevojë për lejet e kërkuara në atë rrjet. Ndryshimet midis abonimeve shpesh dështojnë për leje, dhe gabimi lexohet lehtësisht gabimisht si problem topologjie.

Shkruani intervalet dhe pronarët përpara ndryshimit. Supozimi për secilin prej tyre prodhon një peering që lidhet dhe nuk rrugëton asgjë.

Verifikoni me rrugë efektive, jo me statusin e peering

Shikoni rrugët efektive në ndërfaqen e rrjetit të një ngarkese pune spoke dhe gjeni prefiksin real të rrjetit lokal. Kontrolloni tabelën e rrugëve të nënrrjetit dhe nëse përhapja e rrugëve të portës është çaktivizuar, sepse një rrugë e përcaktuar nga përdoruesi ose një pajisje inspektimi mund të anashkalojë rrugën që sugjerojnë flamujt e peering. Pastaj konfirmoni drejtimin tjetër: rrjeti lokal duhet të dijë si të arrijë prefiksin e spoke përmes lidhjes site-to-site, qoftë me njoftime të mësuara, qoftë me një rrugë eksplicite dhe një zë përkatës të rrjetit të mbrojtur në pajisjen e klientit. Nëse prefiksi mungon në cilëndo anë, flamujt e peering nuk janë ajo që duhet ndryshuar.

Testoni një shërbim nga një ngarkesë pune spoke dhe ndiqni përgjigjen. Një test nga porta VPN ose nga një VM e hub-it ushtron një prefiks burimi dhe një rrugë të ndryshme.

Nëse topologjia u shërben edhe klientëve point-to-site, validoni veçmas rrugët e tyre të instaluara. Paketat e klientit Windows mund të kenë nevojë për rigjenerim pas një ndryshimi të topologjisë, dhe kjo është detyrë e rrugëzimit të klientit, jo provë se ndarja e portës dështoi.

Çfarë nuk jep ndarja e një porte

Transit i portës është komoditet rrugëzimi, jo autorizim. Grupet e sigurisë së rrjetit, filtrat lokalë dhe rregullat në nivel shërbimi ende vendosin se çfarë mund të arrijë një ngarkesë pune spoke, prandaj aktivizoni shërbimin konkret nga burimi në destinacion në vend që të supozoni se tuneli i përbashkët lejon gjithçka pas tij.

Peering gjithashtu nuk është kalimtar ashtu si njerëzit shpresojnë. Shtimi i një spoke tjetër, ose i një pikë fundore private, sjell kërkesat e veta të rrugëzimit dhe aksesit që cilësimi ekzistues i transit nuk i mbulon.