Liikluse marsruutimine kahe haru vahel Azure VPN-lüüsi kaudu
Kaks sait-sait-ühendust ühel Azure VPN-lüüsil saavad harude liiklust läbi lasta, kuid ainult siis, kui mõlemad otsad õpivad prefiksi ja LAN-tagastustee on olemas.
Kaks haru saavad liiklust vahetada Azure VPN-lüüsi kaudu ilma nende vahelise otsese tunnelita. Iga haru avab sait-sait-ühenduse samasse lüüsi ja lüüs edastab õpitud prefiksid kahe ühenduse vahel. Selle toimimise põhjus ei ole teine tunnel, vaid marsruutide vahetus: haru A peab õppima haru B prefiksi ja B A prefiksi. Käige allolevad kontrollid järjekorras läbi ja peatuge esimesel, mis ebaõnnestub, sest iga järgmine samm sõltub sellest.
Eeldused, enne kui midagi seadistate
Neli tingimust otsustavad, kas see lahendus üldse töötada saab. Lüüs peab olema marsruutidel põhinev ja SKU-l, mis toetab BGP-d, mõlemal ühendusel peab BGP olema lubatud, harude aadressiruumid ei tohi kattuda ja kumbki pool ei tohi loota NAT-ile, et oma tegelikku prefiksit varjata.
Planeerige ASN-id teadlikult. Azure'i dokumenteeritud vaikeväärtus on 65515 ja igal haru marsruuteril on vaja oma privaatset ASN-i, mis ei põrka lüüsiga ega teise haruga. Vaikeväärtuse korduskasutamine olemasolevat lüüsi konfiguratsiooni kontrollimata on viis, kuidas AS-tee hiljem tagasi lükatakse.
Kinnitage ka, et te ei oota VNet-i vastastikuse sidumise käitumist. Lüüs vahetab marsruute kahe ühenduse vahel, mille seadistasite; see ei muuda suvalisi vastastikuseid sidumisi transitiivseks. Kui kolmas võrk peab jõudma mõlemasse harusse, vajab see oma ühendust või oma marsruudi teed, mitte eeldust, et lüüs liikluse laiali jagab. Kirjutage see piir üles enne esimest muudatuste akent, sest see on disainiotsus, mille juurde inimesed hiljem saidi lisamisel tagasi pöörduvad.
Seadistage selles järjekorras
Igal sammul on jälgitav tulemus, seega ärge liikuge edasi enne, kui see ilmub.
- Lubage BGP virtuaalvõrgu lüüsil ja märkige üles selle ASN ja partneri aadress.
- Looge iga haru jaoks kohalik võrgulüüs selle haru tegeliku aadressiruumi, ASN-i ja BGP partneri aadressiga.
- Looge iga sait-sait-ühendus ja lubage BGP ühendusel endal.
- Seadistage haru marsruuter vastastikku siduma Azure'i määratud lüüsi aadressiga, mitte eelduslikult lüüsi avaliku IKE-lõppunktiga.
Neljas samm on koht, kus enamik katseid takerdub. Azure'i teatatud BGP partneri aadress on see, mida haru marsruuter peab naabrina kasutama, ja see ei ole alati aadress, mida inimesed tunneliskeemilt ootavad.
Teatage haru prefiks ise, näiteks 10.10.0.0/16 A-st ja 10.20.0.0/16 B-st. Ärge teatage vaikemarsruuti ega laia agregaati, et katta puuduvat konkreetset võrku; tühik tuleb hiljem tagasi vaikse musta auguna.
Kontrollige marsruutide vahetust mõlemas otsas
Ühenduse olek ei ole kontroll. IPsec võib mõlemal ühendusel üleval olla, samal ajal kui ükski prefiks nende vahel ei liigu. Lugege lüüsi BGP partnereid ja õpitud marsruute ning kinnitage seejärel, et marsruut teise haru poole ilmub kasutatava teena.
| 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 |
BGP-tabelis olev prefiks võib ikkagi kaotada edastusotsuse staatilisele marsruudile või täpsemale prefiksile. Kontrollige valitud marsruuti, mitte ainult saadud marsruuti.
Jälgige tagasiteed LAN-i poolel
See on osa, mis näeb Azure'is õige välja ja ebaõnnestub kohapeal. Haru A host saadab oma paketi A VPN-marsruuterile ainult siis, kui see marsruuter on tema vaikelüüs, või kui hostil või selle lüüsil on marsruut B prefiksile. Sama peab kehtima ka vastassuunas.
Kui eraldi tuumkommutaator on LAN-i vaikelüüs, vajab see marsruuti teise haru poole, mis osutab VPN-marsruuterile. Ilma selleta jõuab päring kohale ja vastus lahkub interneti teed pidi ning kasutaja näeb ühendust, mis avaneb ja jääb siis rippuma.
Ärge haarake selle parandamiseks lüüsi alamvõrgu võrguturbegrupist. Sellel alamvõrgul on omad nõuded ja NSG seal ei ole haru poole poliitika toetatud asendaja. Filtreerimine kuulub harude tulemüüridele ja töökoormustele endile, kus reegleid saavad üle vaadata nende omanikud. Nende reeglite alamvõrgu NSG-sse viimine varjab need ka meeskonna eest, kes järgmist riket silub.
Lubage toiming ja tõestage seda seejärel keelatud testiga
Õpitud marsruut ei ole luba. Lubage allikas, sihtkoht ja teenus, mida tegelikult vajate, läbi harude tulemüüride ja lõpp-punkti poliitika, ja jätke ülejäänu keelatuks.
Testige haru A tavalisest töökoormusest haru B päris teenuseni, kinnitage vastus ja proovige seejärel toimingut, mis peaks jääma keelatuks. VPN-seadme enda tekitatud liiklus võib kasutada teist lähteaadressi ja jätta LAN-i marsruutimise etapi vahele, seega tõestab marsruuterilt tehtud edukas ping vähem, kui näib.
Lõpetage nelja fakti üleskirjutamisega: vahetatud prefiksid, kasutatud ASN-id, iga poole LAN-tagasitee ja poliitika, mis teenuse lubab. Kui üks neist puudub, töötab seadistus kuni esimese muudatuseni ja siis ei oska keegi seletada, miks.