Rut trafik mellem to filialer gennem en Azure VPN-gateway
To Site-to-Site-forbindelser på én Azure VPN-gateway kan føre filialtrafik, men kun når begge ender lærer præfikset, og LAN-returvejen findes.
To filialer kan udveksle trafik gennem en Azure VPN-gateway uden nogen direkte tunnel mellem dem. Hver filial åbner en Site-to-Site-forbindelse til den samme gateway, og gatewayen sender de lærte præfikser mellem de to forbindelser. Det, der får dette til at virke, er ikke den anden tunnel, men ruteudvekslingen: filial A skal lære filial B's præfiks, og B skal lære A's. Gå gennem kontrollerne nedenfor i rækkefølge, og stop ved den første, der fejler, fordi hvert senere trin afhænger af det.
Forudsætninger, før du konfigurerer noget
Fire betingelser afgør, om dette design overhovedet kan virke. Gatewayen skal være rutebaseret og på en SKU, der understøtter BGP, begge forbindelser skal have BGP aktiveret, filialernes adresserum må ikke overlappe, og ingen side må stole på NAT for at skjule sit rigtige præfiks.
Planlæg ASN'erne bevidst. Azures dokumenterede standard er 65515, og hver filialrouter har brug for sit eget private ASN, der ikke kolliderer med gatewayen eller den anden filial. Genbrug af en standard uden at kontrollere en eksisterende gatewaykonfiguration er, hvordan en AS-sti senere bliver afvist.
Bekræft også, at du ikke forventer VNet-peering-adfærd. Gatewayen udveksler ruter mellem de to forbindelser, du konfigurerede; den gør ikke vilkårlige peerings transitive. Hvis et tredje netværk skal nå begge filialer, har det brug for sin egen forbindelse eller sin egen rutevej, ikke en antagelse om, at gatewayen vil sprede trafikken. Skriv den grænse ned før det første ændringsvindue, fordi det er den designbeslutning, folk vender tilbage til, når et senere sted tilføjes.
Konfigurer i denne rækkefølge
Hvert trin har et observerbart resultat, så fortsæt ikke, før det vises.
- Aktivér BGP på den virtuelle netværksgateway, og noter dens ASN og peer-adresse.
- Opret en lokal netværksgateway per filial med filialens rigtige adresserum, dens ASN og dens BGP-peer-adresse.
- Opret hver Site-to-Site-forbindelse, og aktivér BGP på selve forbindelsen.
- Konfigurer filialrouteren til at peere med den gatewayadresse, Azure tildelte, ikke med gatewayens offentlige IKE-endpoint ud fra en antagelse.
Det fjerde trin er der, hvor de fleste forsøg går i stå. Den BGP-peer-adresse, Azure rapporterer, er den, filialrouteren skal bruge som nabo, og det er ikke altid den adresse, folk forventer ud fra tunneldiagrammet.
Annoncér selve filialpræfikset, for eksempel 10.10.0.0/16 fra A og 10.20.0.0/16 fra B. Annoncér ikke en standardrute eller et bredt aggregate for at dække et manglende specifikt netværk; hullet kommer tilbage senere som et tavst sort hul.
Bekræft ruteudvekslingen i begge ender
Forbindelsesstatus er ikke kontrollen. IPsec kan være oppe på begge forbindelser, mens intet præfiks krydser mellem dem. Læs gatewayens BGP-peers og dens lærte ruter, og bekræft derefter, at ruten mod den anden filial vises som en brugbar vej.
| 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 præfiks, der findes i en BGP-tabel, kan stadig tabe videresendelsesbeslutningen til en statisk rute eller et mere specifikt præfiks. Kontrollér den valgte rute, ikke kun den modtagne.
Følg returvejen på LAN-siden
Det er den del, der ser rigtig ud i Azure og fejler på stedet. En vært i filial A sender sin pakke til A's VPN-router, kun hvis den router er dens standardgateway, eller hvis værten eller dens gateway har en rute til B's præfiks. Det samme skal gælde i den anden retning.
Hvis en separat coreswitch er LAN'ets standardgateway, har den brug for ruten mod den anden filial pegende på VPN-routeren. Uden den ankommer anmodningen, og svaret forlader gennem internetvejen, og brugeren ser en forbindelse, der åbner og derefter hænger.
Grib ikke efter en netværkssikkerhedsgruppe på gateway-subnettet for at løse dette. Det subnet har sine egne krav, og en NSG der er ikke en understøttet erstatning for politik på filialsiden. Filtrering hører hjemme på filialernes firewalls og på selve arbejdsbyrderne, hvor reglerne kan gennemgås af de folk, der ejer dem. At flytte disse regler til en NSG på subnetnettet skjuler dem også for det team, der skal fejlfinde den næste afbrydelse.
Tillad handlingen, og bevis den derefter med en afvist test
En lært rute er ikke en tilladelse. Tillad den kilde, destination og tjeneste, du faktisk har brug for, gennem filialernes firewalls og endpoint-politikken, og lad resten være afvist.
Test fra en almindelig arbejdsbyrde i filial A til en rigtig tjeneste i filial B, bekræft svaret, og forsøg derefter en handling, der skal forblive forbudt. Trafik genereret af selve VPN-enheden kan bruge en anden kildeadresse og springe LAN-rutningstrinnet over, så en vellykket ping fra routeren beviser mindre, end det ser ud til.
Afslut med at skrive fire fakta ned: de udvekslede præfikser, de anvendte ASN'er, LAN-returvejen for hver side og den politik, der tillader tjenesten. Hvis en af dem mangler, virker opsætningen indtil den første ændring, og derefter kan ingen forklare hvorfor.