Forgalom irányítása két fióktelep között egy Azure VPN-átjárón keresztül
Két Site-to-Site kapcsolat egy Azure VPN-átjárón átviheti a fióktelepek forgalmát, de csak akkor, ha mindkét vég megtanulja az előtagot, és létezik a LAN-visszaút.
Két fióktelep egy Azure VPN-átjárón keresztül cserélhet forgalmat anélkül, hogy közvetlen alagút lenne közöttük. Mindegyik fióktelep Site-to-Site kapcsolatot nyit ugyanahhoz az átjáróhoz, és az átjáró továbbadja a megtanult előtagokat a két kapcsolat között. Ezt nem a második alagút teszi működőképessé, hanem az útvonalak cseréje: az A fióktelepnek meg kell tanulnia a B fióktelep előtagját, a B-nek pedig az A-ét. Végezze el az alábbi ellenőrzéseket sorrendben, és álljon meg az elsőnél, amelyik sikertelen, mert minden későbbi lépés ettől függ.
Előfeltételek, mielőtt bármit konfigurálna
Négy feltétel dönti el, hogy ez a kialakítás egyáltalán működhet-e. Az átjárónak útvonalalapúnak kell lennie, és olyan SKU-n kell futnia, amely támogatja a BGP-t, mindkét kapcsolaton engedélyezve kell lennie a BGP-nek, a fióktelepek címtere nem fedheti át egymást, és egyik oldal sem támaszkodhat NAT-ra a valódi előtag elrejtéséhez.
Tervezze meg az ASN-eket szándékosan. Az Azure dokumentált alapértéke a 65515, és minden fióktelep-útválasztónak saját privát ASN-re van szüksége, amely nem ütközik az átjáróval vagy a másik fiókteleppel. Az alapérték újrafelhasználása a meglévő átjárókonfiguráció ellenőrzése nélkül az az út, amelyen egy AS-útvonal később elutasításra kerül.
Arról is győződjön meg, hogy nem VNet-peering-viselkedést vár. Az átjáró a konfigurált két kapcsolat között cserél útvonalakat; nem teszi tranzitívvá az önkényes peeringeket. Ha egy harmadik hálózatnak el kell érnie mindkét fióktelepet, saját kapcsolatra vagy saját útvonalra van szüksége, nem arra a feltételezésre, hogy az átjáró szétosztja a forgalmat. Írja le ezt a határt az első változási ablak előtt, mert ez az a tervezési döntés, amelyhez az emberek visszatérnek, amikor később új telephelyet adnak hozzá.
Konfiguráljon ebben a sorrendben
Minden lépésnek megfigyelhető eredménye van, ezért ne lépjen tovább, amíg meg nem jelenik.
- Engedélyezze a BGP-t a virtuális hálózati átjárón, és jegyezze fel az ASN-jét és a peer-címét.
- Hozzon létre helyi hálózati átjárót minden fióktelephez annak valódi címtartományával, ASN-jével és BGP peer-címével.
- Hozza létre az egyes Site-to-Site kapcsolatokat, és engedélyezze a BGP-t magán a kapcsolaton.
- Állítsa be a fióktelep-útválasztót, hogy az Azure által kiosztott átjárócímmel peereljen, ne pedig feltételezés alapján az átjáró nyilvános IKE-végpontjával.
A negyedik lépés az, ahol a legtöbb kísérlet elakad. Az Azure által jelentett BGP peer-cím az, amelyet a fióktelep-útválasztónak szomszédként kell használnia, és ez nem mindig az a cím, amelyet az emberek az alagút ábrájából várnak.
Hirdesse meg magát a fióktelep előtagját, például 10.10.0.0/16 az A-ból és 10.20.0.0/16 a B-ből. Ne hirdessen meg alapértelmezett útvonalat vagy széles aggregátumot egy hiányzó konkrét hálózat lefedésére; a hézag később csendes fekete lyukként tér vissza.
Ellenőrizze az útvonalcserét mindkét végén
A kapcsolat állapota nem az ellenőrzés. Az IPsec mindkét kapcsolaton fent lehet, miközben egyetlen előtag sem halad át közöttük. Olvassa ki az átjáró BGP peerjeit és megtanult útvonalait, majd erősítse meg, hogy a másik fióktelep felé vezető útvonal használható útvonalként jelenik meg.
| 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 |
A BGP-táblában szereplő előtag még mindig elveszítheti a továbbítási döntést egy statikus útvonallal vagy egy konkrétabb előtaggal szemben. A kiválasztott útvonalat ellenőrizze, ne csak a fogadottat.
Kövesse a visszautat a LAN oldalán
Ez az a rész, amely Azure-ban helyesnek látszik, a helyszínen viszont meghiúsul. Az A fióktelep egyik gazdagépe csak akkor küldi csomagját az A VPN-útválasztójának, ha az az útválasztó az alapértelmezett átjárója, vagy ha a gazdagépnek vagy az átjárójának van útvonala a B előtagjához. Ugyanennek a másik irányban is igaznak kell lennie.
Ha egy külön magkapcsoló a LAN alapértelmezett átjárója, szüksége van a másik fióktelep felé vezető, a VPN-útválasztóra mutató útvonalra. Enélkül a kérés megérkezik, a válasz pedig az internetes úton távozik, és a felhasználó egy olyan kapcsolatot lát, amely megnyílik, majd megakad.
Ne nyúljon a hálózati biztonsági csoporthoz az átjáró alhálózatán, hogy ezt kijavítsa. Annak az alhálózatnak saját követelményei vannak, és az ott lévő NSG nem támogatott helyettesítője a fióktelep oldali szabályzatnak. A szűrés a fióktelepek tűzfalaira és magukra a számítási feladatokra tartozik, ahol a szabályokat a tulajdonosaik átnézhetik. E szabályok alhálózati NSG-be helyezése elrejti őket a következő kiesést hibakereső csapat elől is.
Engedélyezze a műveletet, majd bizonyítsa egy elutasított teszttel
A megtanult útvonal nem engedély. Engedélyezze a valóban szükséges forrást, célt és szolgáltatást a fióktelepek tűzfalain és a végpontszabályzaton keresztül, a többit pedig hagyja elutasítva.
Teszteljen az A fióktelep egy szokásos számítási feladatából a B fióktelep valódi szolgáltatása felé, erősítse meg a választ, majd próbáljon meg egy műveletet, amelynek tiltottnak kell maradnia. A VPN-eszköz által generált forgalom más forráscímet használhat, és kihagyhatja a LAN-útválasztási szakaszt, ezért az útválasztóról indított sikeres ping kevesebbet bizonyít, mint aminek látszik.
Fejezze be négy tény leírásával: a kicserélt előtagok, a használt ASN-ek, az egyes oldalak LAN-visszaútja és a szolgáltatást engedélyező szabályzat. Ha ezek közül egy hiányzik, a beállítás az első változásig működik, aztán senki sem tudja megmagyarázni, miért.