Rute trafikk mellom to avdelingar gjennom ein Azure VPN-gateway
To Site-to-Site-tilkoplingar på éin Azure VPN-gateway kan føre avdelingstrafikk, men berre når begge endar lærer prefikset og LAN-returvegen finst.
To avdelingar kan utveksle trafikk gjennom ein Azure VPN-gateway utan nokon direkte tunnel mellom dei. Kvar avdeling opnar ei Site-to-Site-tilkopling til same gateway, og gatewayen sender dei lærde prefiksa mellom dei to tilkoplingane. Det som får dette til å verke er ikkje den andre tunnelen, men ruteutvekslinga: avdeling A må lære prefikset til avdeling B, og B må lære A sitt. Gå gjennom kontrollane nedanfor i rekkjefølgje og stopp ved den første som feilar, fordi kvart seinare steg er avhengig av den.
Føresetnader, før du konfigurerer noko
Fire vilkår avgjer om dette designet kan fungere i det heile. Gatewayen må vere rutebasert og på ein SKU som støttar BGP, begge tilkoplingane må ha BGP aktivert, adresseområda til avdelingane må ikkje overlappe, og ingen side kan stole på NAT for å skjule det verkelege prefikset sitt.
Planlegg ASN-ane medvite. Den dokumenterte standardverdien i Azure er 65515, og kvar avdelingsruter treng sin eigen private ASN som ikkje kolliderer med gatewayen eller den andre avdelinga. Å bruke ein standard om att utan å kontrollere ein eksisterande gatewaykonfigurasjon er måten ein AS-sti seinare blir avvist på.
Stadfest òg at du ikkje ventar VNet-peering-åtferd. Gatewayen utvekslar ruter mellom dei to tilkoplingane du konfigurerte; den gjer ikkje vilkårlege peeringar transitive. Dersom eit tredje nettverk må nå begge avdelingane, treng det si eiga tilkopling eller sin eigen ruteveg, ikkje ei føresetnad om at gatewayen vil spreie trafikken. Skriv ned den grensa før det første endringsvindauget, fordi det er designavgjerda folk kjem tilbake til når ein ny stad blir lagd til seinare.
Konfigurer i denne rekkjefølgja
Kvart steg har eit observerbart resultat, så ikkje gå vidare før det viser seg.
- Aktiver BGP på den virtuelle nettverksgatewayen, og noter ASN-en og peer-adressa.
- Opprett ein lokal nettverksgateway per avdeling med det verkelege adresseområdet til avdelinga, ASN-en og BGP-peer-adressa.
- Opprett kvar Site-to-Site-tilkopling, og aktiver BGP på sjølve tilkoplinga.
- Konfigurer avdelingsruteren til å peere med gatewayadressa Azure tildelte, ikkje med den offentlege IKE-endepunktet til gatewayen ut frå ei føresetnad.
Det fjerde steget er der dei fleste forsøka stoppar. BGP-peer-adressa Azure rapporterer er den avdelingsruteren må bruke som nabo, og det er ikkje alltid adressa folk ventar frå tunneldiagrammet.
Annonser sjølve avdelingsprefikset, til dømes 10.10.0.0/16 frå A og 10.20.0.0/16 frå B. Ikkje annonser ei standardrute eller eit breitt aggregate for å dekkje eit manglande spesifikt nettverk; gapet kjem tilbake seinare som eit stille svart hol.
Stadfest ruteutvekslinga i begge endar
Tilkoplingsstatus er ikkje kontrollen. IPsec kan vere oppe på begge tilkoplingane medan ingen prefiks kryssar mellom dei. Les BGP-peerane til gatewayen og dei lærde rutene, og stadfest deretter at ruta mot den andre avdelinga viser seg som ein brukbar veg.
| 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 |
Eit prefiks som finst i ein BGP-tabell kan likevel tape vidaresendingsavgjerda til ei statisk rute eller eit meir spesifikt prefiks. Kontroller den valde ruta, ikkje berre den mottekne.
Følg returvegen på LAN-sida
Dette er delen som ser rett ut i Azure og feilar på staden. Ein vert i avdeling A sender pakken sin til VPN-ruteren til A berre dersom den ruteren er standardgatewayen, eller dersom verten eller gatewayen har ei rute for B-prefikset. Det same må gjelde i den andre retninga.
Dersom ein separat kjernesvitsj er standardgatewayen i LAN-et, treng han ruta mot den andre avdelinga som peikar på VPN-ruteren. Utan henne kjem førespurnaden inn og svaret går ut via internettvegen, og brukaren ser ei tilkopling som opnar og deretter heng.
Ikkje grip etter ei nettverkssikkerheitsgruppe på gateway-subnettet for å fikse dette. Det subnettet har sine eigne krav, og ein NSG der er ikkje ein støtta erstatning for policy på avdelingssida. Filtrering høyrer heime på brannmurane til avdelingane og på sjølve arbeidslastene, der reglane kan bli gjennomgått av dei som eig dei. Å flytte desse reglane til ein NSG på subnettet skjuler dei òg for teamet som skal feilsøkje neste avbrot.
Tillat operasjonen, og prov det deretter med ein avvist test
Ei lærd rute er ikkje ei tillating. Tillat kjelda, destinasjonen og tenesta du faktisk treng gjennom brannmurane til avdelingane og endepunktspolicyen, og lat resten vere avvist.
Test frå ei vanleg arbeidslast i avdeling A til ei verkeleg teneste i avdeling B, stadfest svaret, og prøv deretter ein operasjon som skal halde fram med å vere forboden. Trafikk som VPN-eininga sjølv genererer kan bruke ei anna kjeldeadresse og hoppe over LAN-rutingsteget, så ein vellukka ping frå ruteren provar mindre enn det ser ut som.
Avslutt med å skrive ned fire fakta: prefiksa som vart utveksla, ASN-ane som blir brukte, LAN-returvegen for kvar side og policyen som tillèt tenesta. Dersom eitt av dei manglar, verkar oppsettet til den første endringa, og då kan ingen forklare kvifor.