Rute trafikk mellom to avdelinger gjennom en Azure VPN-gateway
To Site-to-Site-tilkoblinger på én Azure VPN-gateway kan føre avdelingstrafikk, men bare når begge ender lærer prefikset og LAN-returveien finnes.
To avdelinger kan utveksle trafikk gjennom en Azure VPN-gateway uten noen direkte tunnel mellom dem. Hver avdeling åpner en Site-to-Site-tilkobling til samme gateway, og gatewayen sender de lærte prefiksene mellom de to tilkoblingene. Det som får dette til å virke er ikke den andre tunnelen, men ruteutvekslingen: avdeling A må lære prefikset til avdeling B, og B må lære A sitt. Gå gjennom kontrollene nedenfor i rekkefølge og stopp ved den første som feiler, fordi hvert senere trinn avhenger av den.
Forutsetninger, før du konfigurerer noe
Fire betingelser avgjør om dette designet kan fungere i det hele tatt. Gatewayen må være rutebasert og på en SKU som støtter BGP, begge tilkoblingene må ha BGP aktivert, adresseområdene til avdelingene må ikke overlappe, og ingen side kan stole på NAT for å skjule sitt virkelige prefiks.
Planlegg ASN-ene bevisst. Den dokumenterte standardverdien i Azure er 65515, og hver avdelingsruter trenger sin egen private ASN som ikke kolliderer med gatewayen eller den andre avdelingen. Å gjenbruke en standard uten å kontrollere en eksisterende gatewaykonfigurasjon er måten en AS-sti senere blir avvist på.
Bekreft også at du ikke forventer VNet-peering-atferd. Gatewayen utveksler ruter mellom de to tilkoblingene du konfigurerte; den gjør ikke vilkårlige peeringer transitive. Hvis et tredje nettverk må nå begge avdelingene, trenger det sin egen tilkobling eller sin egen rutevei, ikke en antakelse om at gatewayen vil spre trafikken. Skriv ned den grensen før det første endringsvinduet, fordi det er designbeslutningen folk kommer tilbake til når et nytt sted legges til senere.
Konfigurer i denne rekkefølgen
Hvert trinn har et observerbart resultat, så ikke gå videre før det vises.
- Aktiver BGP på den virtuelle nettverksgatewayen, og noter ASN-en og peer-adressen.
- Opprett en lokal nettverksgateway per avdeling med avdelingens virkelige adresseområde, ASN-en og BGP-peer-adressen.
- Opprett hver Site-to-Site-tilkobling, og aktiver BGP på selve tilkoblingen.
- Konfigurer avdelingsruteren til å peere med gatewayadressen Azure tildelte, ikke med gatewayens offentlige IKE-endepunkt ut fra en antakelse.
Det fjerde trinnet er der de fleste forsøkene stopper. BGP-peer-adressen Azure rapporterer er den avdelingsruteren må bruke som nabo, og det er ikke alltid adressen folk forventer fra tunneldiagrammet.
Annonser selve avdelingsprefikset, for eksempel 10.10.0.0/16 fra A og 10.20.0.0/16 fra B. Ikke annonser en standardrute eller et bredt aggregate for å dekke et manglende spesifikt nettverk; gapet kommer tilbake senere som et stille svart hull.
Verifiser ruteutvekslingen i begge ender
Tilkoblingsstatus er ikke kontrollen. IPsec kan være oppe på begge tilkoblingene mens ingen prefiks krysser mellom dem. Les gatewayens BGP-peers og de lærte rutene, og bekreft deretter at ruten mot den andre avdelingen vises som en brukbar vei.
| 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 |
Et prefiks som finnes i en BGP-tabell kan likevel tape videresendingsbeslutningen til en statisk rute eller et mer spesifikt prefiks. Kontroller den valgte ruten, ikke bare den mottatte.
Følg returveien på LAN-siden
Dette er delen som ser riktig ut i Azure og feiler på stedet. En vert i avdeling A sender pakken sin til A sin VPN-ruter bare hvis den ruteren er standardgatewayen, eller hvis verten eller gatewayen har en rute for B-prefikset. Det samme må gjelde i den andre retningen.
Hvis en separat kjernesvitsj er standardgatewayen i LAN-et, trenger den ruten mot den andre avdelingen som peker på VPN-ruteren. Uten den kommer forespørselen inn og svaret går ut via internettveien, og brukeren ser en tilkobling som åpnes og deretter henger.
Ikke grip etter en nettverkssikkerhetsgruppe på gateway-subnettet for å fikse dette. Det subnettet har sine egne krav, og en NSG der er ikke en støttet erstatning for policy på avdelingssiden. Filtrering hører hjemme på avdelingenes brannmurer og på selve arbeidsbelastningene, der reglene kan gjennomgås av dem som eier dem. Å flytte disse reglene til en NSG på subnettet skjuler dem også for teamet som skal feilsøke neste avbrudd.
Tillat operasjonen, og bevis den deretter med en avvist test
En lært rute er ikke en tillatelse. Tillat kilden, destinasjonen og tjenesten du faktisk trenger gjennom avdelingenes brannmurer og endepunktspolicyen, og la resten være avvist.
Test fra en vanlig arbeidsbelastning i avdeling A til en ekte tjeneste i avdeling B, bekreft svaret, og forsøk deretter en operasjon som skal forbli forbudt. Trafikk som VPN-enheten selv genererer kan bruke en annen kildeadresse og hoppe over LAN-rutingstrinnet, så en vellykket ping fra ruteren beviser mindre enn det ser ut som.
Avslutt med å skrive ned fire fakta: prefiksene som ble utvekslet, ASN-ene som brukes, LAN-returveien for hver side og policyen som tillater tjenesten. Hvis ett av dem mangler, virker oppsettet til den første endringen, og da kan ingen forklare hvorfor.