Leiða umferð milli tveggja útibúa í gegnum Azure VPN-gátt
Tvær Site-to-Site-tengingar á einni Azure VPN-gátt geta flutt umferð útibúanna, en aðeins þegar báðir endar læra forskeytið og LAN-afturleiðin er til staðar.
Tvö útibú geta skipt umferð sín á milli í gegnum Azure VPN-gátt án nokkurrar beinnar göngu á milli þeirra. Hvert útibú opnar Site-to-Site-tengingu við sömu gáttina, og gáttin sendir lærðu forskeytin milli tenginganna tveggja. Það sem lætur þetta virka er ekki önnur göngin heldur leiðaskiptin: útibú A verður að læra forskeyti útibús B, og B forskeyti A. Farið í gegnum prófanirnar hér að neðan í réttri röð og stöðvið við þá fyrstu sem mistekst, því hvert síðara skref veltur á henni.
Forsendur, áður en þú stillir nokkuð
Fjögur skilyrði ráða því hvort þessi hönnun getur yfirhöfuð virkað. Gáttin verður að vera leiðamiðuð og á SKU sem styður BGP, BGP verður að vera virkt á báðum tengingum, vistföng útibúanna mega ekki skarast, og hvorugur aðili má reiða sig á NAT til að fela raunverulegt forskeyti sitt.
Skipuleggðu ASN-in viljandi. Skjalfest sjálfgefið gildi Azure er 65515, og hver útibúsleiðari þarf sína eigin einkareknu ASN sem rekst ekki á gáttina eða hitt útibúið. Endurnotkun sjálfgefins gildis án þess að athuga fyrirliggjandi gáttarstillingu er leiðin sem AS-slóð er hafnað síðar.
Staðfestið einnig að þið séuð ekki að búast við VNet-peeringhegðun. Gáttin skiptir leiðum milli tenginganna tveggja sem þið stilltuð; hún gerir handahófskennd peering ekki gegnumstreymis. Ef þriðja netið þarf að ná til beggja útibúa þarf það eigin tengingu eða eigin leiðslóð, ekki þá forsendu að gáttin dreifi umferðinni. Skrifið þessi mörk niður fyrir fyrsta breytingagluggann, því þetta er hönnunarákvörðunin sem fólk snýr aftur að þegar nýr staður er bætt við síðar.
Stillið í þessari röð
Hvert skref hefur sjáanlega niðurstöðu, svo farið ekki áfram fyrr en hún birtist.
- Virkjið BGP á gátt sýndarnetsins og skráið ASN hennar og peer-tölu.
- Búið til staðbundið netgátt fyrir hvert útibú með raunverulegu vistfangi þess útibús, ASN þess og BGP-peer-tölu þess.
- Búið til hverja Site-to-Site-tengingu og virkjið BGP á tengingunni sjálfri.
- Stillið útibúsleiðarann til að peera við gáttartöluna sem Azure úthlutaði, ekki við opinbera IKE-endapunkt gáttarinnar að gefinni forsendu.
Fjórða skrefið er þar sem flestar tilraunir stöðvast. BGP-peer-talan sem Azure tilkynnir er sú sem útibúsleiðarinn verður að nota sem nágranna, og hún er ekki alltaf talan sem fólk býst við út frá gönguskýringunni.
Tilkynnið forskeyti útibúsins sjálfs, til dæmis 10.10.0.0/16 frá A og 10.20.0.0/16 frá B. Tilkynnið ekki sjálfgefna leið eða breitt safn til að hylja vantað tiltekið net; bilið kemur aftur síðar sem hljóðlátur svarthol.
Staðfestið leiðaskiptin á báðum endum
Staða tengingarinnar er ekki prófunin. IPsec getur verið virkt á báðum tengingum á meðan ekkert forskeyti fer á milli þeirra. Lesið BGP-peer gáttarinnar og lærðu leiðir hennar, og staðfestið síðan að leiðin til hins útibúsins birtist sem nothæf slóð.
| 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 |
Forskeyti sem er í BGP-töflu getur samt tapað sendingarákvörðuninni fyrir kyrrstæðri leið eða nákvæmara forskeyti. Athugið valdu leiðina, ekki aðeins þá mótteknu.
Fylgið afturleiðinni á LAN-hliðinni
Þetta er hlutinn sem lítur rétt út í Azure og mistekst á staðnum. Hýsill í útibúi A sendir pakkann sinn til VPN-leiðara A aðeins ef sá leiðari er sjálfgefna gátt hans, eða ef hýsillinn eða gátt hans hefur leið fyrir forskeyti B. Sama verður að gilda í hina áttina.
Ef sérstakur kjarnaskiptir er sjálfgefna gátt LAN-sins þarf hann leiðina til hins útibúsins sem bendir á VPN-leiðarann. Án hennar kemur beiðnin og svarið fer út um internetleiðina, og notandinn sér tengingu sem opnast og stendur svo kyrr.
Gripið ekki til netöryggishóps á gáttarundirnetinu til að laga þetta. Það undirnet hefur sínar eigin kröfur og NSG þar er ekki studd staðganga fyrir stefnu á útibúshliðinni. Síun á heima á eldveggjum útibúanna og á sjálfum vinnuálaginu, þar sem eigendur geta farið yfir reglurnar. Að flytja þessar reglur í NSG undirnetsins felur þær líka fyrir teyminu sem mun kemba næstu bilun.
Leyfið aðgerðina og sannið hana svo með höfnuðu prófi
Lærð leið er ekki leyfi. Leyfið uppruna, áfangastað og þjónustu sem þið þurfið í raun í gegnum eldveggi útibúanna og endapunktastefnuna, og látið restina vera hafnaða.
Prófið frá venjulegu vinnuálagi í útibúi A til raunverulegrar þjónustu í útibúi B, staðfestið svarið og reynið síðan aðgerð sem á að vera bönnuð áfram. Umferð sem VPN-tækið sjálft myndar getur notað aðra upprunatölu og sleppt LAN-leiðavögunarþrepinu, svo árangursríkt ping frá leiðaranum sannar minna en virðist.
Ljúkið með því að skrifa niður fjögur staðreyndir: forskeytin sem skipt var, ASN-in í notkun, LAN-afturleið hvors aðila og stefnuna sem leyfir þjónustuna. Ef eitt þeirra vantar virkar uppsetningin þangað til fyrsta breytingin verður, og þá getur enginn útskýrt hvers vegna.