Směrování provozu mezi dvěma pobočkami přes bránu Azure VPN
Dvě připojení Site-to-Site na jedné bráně Azure VPN mohou přenášet provoz poboček, ale jen tehdy, když oba konce znají prefix a existuje zpětná cesta v LAN.
Dvě pobočky mohou vyměňovat provoz přes bránu Azure VPN bez jakéhokoli přímého tunelu mezi sebou. Každá pobočka otevře připojení Site-to-Site ke stejné bráně a brána předává naučené prefixy mezi oběma připojeními. Funguje to ne díky druhému tunelu, ale díky výměně tras: pobočka A se musí naučit prefix pobočky B a B zase prefix A. Projděte níže uvedené kontroly v pořadí a zastavte se u první, která selže, protože na ní závisí každý další krok.
Předpoklady, než cokoli nakonfigurujete
O tom, zda tento návrh vůbec může fungovat, rozhodují čtyři podmínky. Brána musí být založená na trasách a na SKU, které podporuje BGP, obě připojení musí mít zapnutý BGP, adresní prostory poboček se nesmějí překrývat a žádná strana nesmí spoléhat na NAT, aby skryla svůj skutečný prefix.
ASN plánujte záměrně. Dokumentovaná výchozí hodnota v Azure je 65515 a každý směrovač pobočky potřebuje vlastní privátní ASN, které nekoliduje s bránou ani s druhou pobočkou. Opětovné použití výchozí hodnoty bez kontroly stávající konfigurace brány je způsob, jakým je cesta AS později odmítnuta.
Také se ujistěte, že nečekáte chování partnerského vztahu VNet. Brána vyměňuje trasy mezi dvěma připojeními, která jste nakonfigurovali; nedělá libovolná partnerská propojení tranzitivními. Pokud má třetí síť dosáhnout obou poboček, potřebuje vlastní připojení nebo vlastní cestu trasy, ne předpoklad, že brána provoz rozvede. Zapište tuto hranici ještě před prvním oknem změn, protože je to rozhodnutí o návrhu, ke kterému se lidé vracejí, když se později přidá další lokalita.
Konfigurujte v tomto pořadí
Každý krok má pozorovatelný výsledek, takže nepokračujte, dokud se neobjeví.
- Zapněte BGP na bráně virtuální sítě a poznamenejte si její ASN a adresu partnera.
- Vytvořte místní síťovou bránu pro každou pobočku s jejím skutečným adresním prostorem, jejím ASN a adresou partnera BGP.
- Vytvořte každé připojení Site-to-Site a zapněte BGP na samotném připojení.
- Nakonfigurujte směrovač pobočky, aby se propojil s adresou brány, kterou Azure přiřadil, nikoli s veřejným koncovým bodem IKE brány na základě předpokladu.
Čtvrtý krok je místo, kde většina pokusů uvízne. Adresa partnera BGP, kterou Azure hlásí, je ta, kterou musí směrovač pobočky použít jako souseda, a ne vždy jde o adresu, kterou lidé očekávají z diagramu tunelu.
Inzerujte samotný prefix pobočky, například 10.10.0.0/16 z A a 10.20.0.0/16 z B. Neinzerujte výchozí trasu ani široký agregát, abyste zakryli chybějící konkrétní síť; mezera se později vrátí jako tichá černá díra.
Ověřte výměnu tras na obou koncích
Stav připojení není kontrola. IPsec může být na obou připojeních zapnutý, aniž by mezi nimi přecházel jediný prefix. Přečtěte si partnery BGP brány a její naučené trasy a poté potvrďte, že se trasa k druhé pobočce objevuje jako použitelná cesta.
| 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 |
Prefix přítomný v tabulce BGP může stále prohrát rozhodnutí o předávání se statickou trasou nebo konkrétnějším prefixem. Kontrolujte vybranou trasu, ne jen přijatou.
Sledujte zpětnou cestu na straně LAN
Tohle je část, která vypadá v Azure správně a na místě selhává. Host v pobočce A pošle svůj paket směrovači VPN pobočky A jen tehdy, když je tento směrovač jeho výchozí bránou, nebo když hostitel nebo jeho brána drží trasu k prefixu B. Totéž musí platit v opačném směru.
Pokud je samostatný páteřní přepínač výchozí bránou LAN, potřebuje trasu k druhé pobočce směřující na směrovač VPN. Bez ní požadavek dorazí a odpověď odejde internetovou cestou a uživatel vidí spojení, které se otevře a pak zamrzne.
Neřešte to skupinou zabezpečení sítě v podsíti brány. Tato podsíť má vlastní požadavky a NSG tam není podporovanou náhradou politiky na straně pobočky. Filtrování patří na brány firewall poboček a na samotné úlohy, kde pravidla mohou kontrolovat jejich vlastníci. Přesun těchto pravidel do NSG podsítě je navíc skryje před týmem, který bude ladit příští výpadek.
Povolte operaci a pak ji dokažte odmítnutým testem
Naučená trasa není oprávnění. Povolte zdroj, cíl a službu, které skutečně potřebujete, přes brány firewall poboček a politiku koncového bodu, a zbytek nechte odmítnutý.
Testujte z běžné úlohy v pobočce A na skutečnou službu v pobočce B, potvrďte odpověď a potom zkuste operaci, která má zůstat zakázaná. Provoz generovaný samotným zařízením VPN může použít jinou zdrojovou adresu a přeskočit fázi směrování v LAN, takže úspěšný ping ze směrovače dokazuje méně, než se zdá.
Na závěr zapište čtyři fakta: vyměněné prefixy, použité ASN, zpětnou cestu LAN pro každou stranu a politiku, která službu povoluje. Pokud jedno z nich chybí, nastavení funguje do první změny a pak už nikdo nedokáže vysvětlit proč.