Maršrutizuoti srautą tarp dviejų filialų per Azure VPN tinklų sietuvą
Dvi site-to-site jungtys viename Azure VPN tinklų sietuvo gali praleisti filialų srautą, bet tik kai abu galai išmoksta priešdėlį ir egzistuoja LAN grįžimo kelias.
Du filialai gali keistis srautu per Azure VPN tinklų sietuvą be jokio tiesioginio tunelio tarp jų. Kiekvienas filialas atidaro site-to-site jungtį prie to paties tinklų sietuvo, o sietuvas perduoda išmoktus priešdėlius tarp dviejų jungčių. Tai veikia ne dėl antrojo tunelio, o dėl maršrutų mainų: filialas A turi išmokti filialo B priešdėlį, o B – A priešdėlį. Peržiūrėkite toliau pateiktus patikrinimus iš eilės ir sustokite ties pirmuoju, kuris nepavyksta, nes kiekvienas vėlesnis žingsnis nuo jo priklauso.
Būtinosios sąlygos prieš ką nors konfigūruojant
Keturių sąlygų pakanka nuspręsti, ar ši konstrukcija apskritai gali veikti. Tinklų sietuvas turi būti maršrutų pagrindu ir veikti SKU, kuris palaiko BGP, abiejose jungtyse turi būti įjungtas BGP, filialų adresų erdvės neturi persidengti, ir nė viena pusė negali pasikliauti NAT, kad paslėptų savo tikrąjį priešdėlį.
ASN planuokite sąmoningai. Dokumentuota Azure numatytoji reikšmė yra 65515, o kiekvienam filialo maršrutizatoriui reikia savo privataus ASN, kuris nesutaptų su tinklų sietuvu ar kitu filialu. Numatytoją naudoti iš naujo netikrinus esamos tinklų sietuvo konfigūracijos – tai būdas, kuriuo AS kelias vėliau atmetamas.
Taip pat patvirtinkite, kad nesitikite VNet peering elgsenos. Tinklų sietuvas keičiasi maršrutais tarp dviejų sukonfigūruotų jungčių; jis nepadaro savavališkų peering ryšių tranzityviais. Jei trečiasis tinklas turi pasiekti abu filialus, jam reikia savo jungties arba savo maršruto kelio, o ne prielaidos, kad tinklų sietuvas išdalins srautą. Užrašykite šią ribą prieš pirmąjį pakeitimų langą, nes tai yra projektinis sprendimas, prie kurio žmonės grįžta vėliau pridedant naują vietą.
Konfigūruokite šia tvarka
Kiekvienas žingsnis turi stebimą rezultatą, todėl neikite toliau, kol jis nepasirodys.
- Įjunkite BGP virtualaus tinklo tinklų sietuve ir užsirašykite jo ASN bei peer adresą.
- Sukurkite vietinį tinklo tinklų sietuvą kiekvienam filialui su to filialo tikra adresų erdve, jo ASN ir BGP peer adresu.
- Sukurkite kiekvieną site-to-site jungtį ir įjunkite BGP pačioje jungtyje.
- Sukonfigūruokite filialo maršrutizatorių, kad jis peerintų su Azure priskirtu tinklų sietuvo adresu, o ne su viešuoju tinklų sietuvo IKE endpoint pagal prielaidą.
Ketvirtasis žingsnis – vieta, kurioje įstringa dauguma bandymų. Azure pranešamas BGP peer adresas yra tas, kurį filialo maršrutizatorius turi naudoti kaip kaimyną, ir tai ne visada adresas, kurio žmonės tikisi iš tunelio schemos.
Skelbkite patį filialo priešdėlį, pavyzdžiui, 10.10.0.0/16 iš A ir 10.20.0.0/16 iš B. Neskelbkite numatytojo maršruto ar plataus agregato, kad padengtumėte trūkstamą konkretų tinklą; spraga vėliau sugrįžta kaip tylioji juodoji skylė.
Patikrinkite maršrutų mainus abiejuose galuose
Jungties būsena nėra patikrinimas. IPsec gali būti aktyvus abiejose jungtyse, kol tarp jų neperduodamas nė vienas priešdėlis. Perskaitykite tinklų sietuvo BGP peer ir jo išmoktus maršrutus, tada patvirtinkite, kad maršrutas kito filialo link pasirodo kaip naudojamas kelias.
| 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 |
Priešdėlis, esantis BGP lentelėje, vis tiek gali pralaimėti persiuntimo sprendimą statiniam maršrutui ar konkretesniam priešdėliui. Tikrinkite pasirinktą maršrutą, o ne tik gautąjį.
Sekite grįžimo kelią LAN pusėje
Tai dalis, kuri Azure atrodo teisingai, o vietoje nepavyksta. Filialo A hostas siunčia savo paketą A VPN maršrutizatoriui tik tada, kai tas maršrutizatorius yra jo numatytasis tinklų sietuvas, arba kai hostas ar jo tinklų sietuvas turi maršrutą B priešdėliui. Tas pats turi galioti ir priešinga kryptimi.
Jei atskiras pagrindinis komutatorius yra LAN numatytasis tinklų sietuvas, jam reikia maršruto kito filialo link, nukreipto į VPN maršrutizatorių. Be jo užklausa atkeliauja, o atsakymas išeina interneto keliu, ir naudotojas mato ryšį, kuris atsidaro ir tada pakimba.
Nesinaudokite tinklo saugos grupe tinklų sietuvo potinklyje, kad tai sutvarkytumėte. Tas potinklis turi savo reikalavimus, o NSG ten nėra palaikomas filialo pusės politikos pakaitalas. Filtravimas priklauso filialų užkardams ir patiems darbo krūviams, kur taisykles gali peržiūrėti jų savininkai. Šių taisyklių perkėlimas į potinklio NSG taip pat paslepia jas nuo komandos, kuri derins kitą gedimą.
Leiskite operaciją, tada įrodykite ją atmestu testu
Išmoktas maršrutas nėra leidimas. Leiskite šaltinį, paskirties vietą ir paslaugą, kurių iš tikrųjų reikia, per filialų užkardus ir endpoint politiką, o likusią dalį palikite atmestą.
Išbandykite iš įprasto darbo krūvio filiale A į tikrą paslaugą filiale B, patvirtinkite atsakymą, tada pabandykite operaciją, kuri turi likti uždrausta. VPN įrenginio sugeneruotas srautas gali naudoti kitą šaltinio adresą ir praleisti LAN maršrutizavimo etapą, todėl sėkmingas ping iš maršrutizatoriaus įrodo mažiau, nei atrodo.
Užbaikite užrašydami keturis faktus: apsikeistus priešdėlius, naudojamus ASN, kiekvienos pusės LAN grįžimo kelią ir politiką, kuri leidžia paslaugą. Jei vieno jų trūksta, sąranka veikia iki pirmo pakeitimo, o tada niekas negali paaiškinti, kodėl.