Verkeer tussen twee takke deur 'n Azure VPN-gateway laat loop
Twee Site-to-Site-verbindings op een Azure VPN-gateway kan takverkeer deurlaat, maar net wanneer beide kante die voorvoegsel leer en die LAN-terugroete bestaan.
Twee takke kan verkeer deur 'n Azure VPN-gateway uitruil sonder enige direkte tonnel tussen hulle. Elke tak open 'n Site-to-Site-verbinding na dieselfde gateway, en die gateway gee die aangeleerde voorvoegsels tussen die twee verbindings deur. Wat dit laat werk, is nie die tweede tonnel nie, maar die roete-uitruiling: tak A moet tak B se voorvoegsel leer, en B moet s'n leer. Werk die kontroles hieronder in volgorde deur en stop by die eerste een wat misluk, want elke latere stap hang daarvan af.
Voorwaardes, voordat jy enigiets opstel
Vier voorwaardes bepaal of hierdie ontwerp hoegenaamd kan werk. Die gateway moet roete-gebaseerd wees en op 'n SKU wat BGP ondersteun, beide verbindings moet BGP geaktiveer hê, die tak-adresruimtes mag nie oorvleuel nie, en geen kant mag op NAT staatmaak om sy werklike voorvoegsel te verberg nie.
Beplan die ASN's doelbewus. Azure se gedokumenteerde verstek is 65515, en elke takroeteerder het sy eie private ASN nodig wat nie met die gateway of die ander tak bots nie. Om 'n verstek te hergebruik sonder om 'n bestaande gateway-konfigurasie na te gaan, is hoe 'n AS-pad later verwerp word.
Bevestig ook dat jy nie VNet-peering-gedrag verwag nie. Die gateway ruil roetes uit tussen die twee verbindings wat jy opgestel het; dit maak nie arbitrêre peerings transitief nie. As 'n derde netwerk albei takke moet bereik, het dit sy eie verbinding of sy eie roetepad nodig, nie die aanname dat die gateway verkeer gaan uitwaaier nie. Skryf daardie grens neer voor die eerste veranderingsvenster, want dit is die ontwerpbesluit wat mense herbesoek wanneer 'n later perseel bygevoeg word.
Stel in hierdie volgorde op
Elke stap het 'n waarneembare resultaat, so moenie aanbeweeg voordat dit verskyn nie.
- Aktiveer BGP op die virtuele netwerk-gateway en noteer sy ASN en eweknie-adres.
- Skep 'n plaaslike netwerk-gateway per tak met daardie tak se werklike adresruimte, sy ASN en sy BGP-eweknie-adres.
- Skep elke Site-to-Site-verbinding en aktiveer BGP op die verbinding self.
- Stel die takroeteerder op om met die gateway-adres wat Azure toegewys het te peer, nie met die gateway se publieke IKE-eindpunt op grond van 'n aanname nie.
Stap vier is waar die meeste pogings vasval. Die BGP-eweknie-adres wat Azure rapporteer, is die een wat die takroeteerder as sy buur moet gebruik, en dit is nie altyd die adres wat mense uit die tonneldiagram verwag nie.
Adverteer die takvoorvoegsel self, byvoorbeeld 10.10.0.0/16 van A en 10.20.0.0/16 van B. Moenie 'n verstekroete of 'n wye samevatting adverteer om 'n ontbrekende spesifieke netwerk te dek nie; die gaping kom later terug as 'n stil swart gat.
Verifieer die roete-uitruiling aan albei kante
Verbindingstatus is nie die kontrole nie. IPsec kan op albei verbindings op wees terwyl geen voorvoegsel tussen hulle oorgaan nie. Lees die gateway se BGP-eweknieë en sy aangeleerde roetes, en bevestig dan dat die roete na die ander tak as 'n bruikbare pad verskyn.
| 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 |
'n Voorvoegsel wat in 'n BGP-tabel voorkom, kan steeds die aanstuur-besluit verloor teenoor 'n statiese roete of 'n meer spesifieke voorvoegsel. Kontroleer die gekose roete, nie net die ontvangde een nie.
Volg die terugroete aan die LAN-kant
Dit is die deel wat in Azure korrek lyk en op die perseel misluk. 'n Gasheer in tak A stuur sy pakket na A se VPN-roeteerder net as daardie roeteerder sy verstek-gateway is, of as die gasheer of sy gateway 'n roete vir B se voorvoegsel het. Dieselfde moet in die ander rigting geld.
As 'n aparte kernskakelaar die LAN se verstek-gateway is, het dit die roete na die ander tak nodig wat na die VPN-roeteerder wys. Sonder dit kom die versoek aan en verlaat die antwoord deur die internetpad, en die gebruiker sien 'n verbinding wat oopgaan en dan hang.
Moenie na 'n netwerksekuriteitsgroep op die gateway-subnet gryp om dit reg te maak nie. Daardie subnet het sy eie vereistes en 'n NSG daar is nie 'n ondersteunde plaasvervanger vir tak-kant-beleid nie. Filtering hoort op die tak-brandmure en op die werkladinge self, waar die reëls deur die mense wat dit besit nagegaan kan word. Om daardie reëls na 'n subnet-NSG te skuif, verberg hulle ook van die span wat die volgende onderbreking gaan ontfout.
Laat die bedryf toe, bewys dit dan met 'n geweierde toets
'n Aangeleerde roete is nie 'n toestemming nie. Laat die bron, bestemming en diens wat jy werklik nodig het deur die tak-brandmure en die eindpunt-beleid, en laat die res geweier.
Toets van 'n gewone werklading in tak A na 'n werklike diens in tak B, bevestig die antwoord, en probeer dan 'n bewerking wat verbode moet bly. Verkeer wat deur die VPN-toestel self gegenereer word, kan 'n ander bronadres gebruik en die LAN-roeteringstap oorslaan, so 'n suksesvolle ping vanaf die roeteerder bewys minder as wat dit lyk.
Eindig deur vier feite neer te skryf: die voorvoegsels wat uitgeruil is, die ASN's in gebruik, die LAN-terugroete vir elke kant, en die beleid wat die diens toelaat. As een van hulle ontbreek, werk die opstelling tot die eerste verandering, en dan kan niemand verduidelik waarom nie.