Potrebuje Azure VNet prepojený cez peering vlastnú bránu VPN?
VNet prepojený cez peering môže používať bránu VPN hubu s podporovaným SKU a jedným nastavením v každom smere peeringu. Overujte efektívne trasy, nie stav peeringu.
Objaví sa nový spoke VNet, hub už má funkčnú bránu site-to-site a nasnade je otázka, či musíte platiť za druhú bránu. Zvyčajne nie: tranzit brány umožňuje spoku využívať bránu hubu cez peering. O tom, či to bude fungovať, rozhodujú tri podmienky a žiadnu z nich nevidíte na odznaku stavu peeringu. Pripojenie cez peering a oprávnenie používať cudziu bránu sú samostatné nastavenia, takže dva VM, ktoré už na seba vedia pingovať, nič nedokazujú o ceste VPN.
Prvá podmienka: brána a jej absencia v spoke
Azure podporuje tranzit brány pre SKU VPN Gateway iné ako Basic a uniesť ho môže regionálny aj globálny peering. Spoke spotrebúva bránu, ktorú nevlastní, takže nemôže mať vlastnú: ak v spoke už brána existuje alebo je už zvolená možnosť vzdialenej brány, nastavenie tranzitu, ktoré chcete, bude nedostupné alebo neúčinné. Overte to, skôr než začnete čokoľvek ladiť, pretože zašednuté zaškrtávacie pole je príznak, nie porucha. Najprv si prečítajte SKU a existujúcu bránu, až potom sa pozrite na nastavenia peeringu.
Nemažte existujúcu bránu spoke len preto, aby sa možnosť objavila, kým neviete, čo od nej závisí. Poradie migrácie je dôležitejšie než zaškrtávacie pole.
Druhá podmienka: jedno nastavenie v každom smere peeringu
Peering sú dva objekty, jeden na každom VNet, a nastavenia tranzitu žijú na rôznych stranách tejto dvojice. Peering hubu smerom k spoke musí bráne hubu dovoliť obsluhovať spoke; peering spoke smerom k hubu musí bránu hubu prijať. Príručka tranzitu brány od Microsoftu ich pomenúva podľa smeru, a to je jediný spôsob, ako ich udržať správne:
| Peering direction | What to enable |
|---|---|
| Hub → spoke | Allow gateway transit on the hub's peering |
| Spoke → hub | Use remote gateways on the spoke's peering |
Ovládací prvok označený remote mení význam podľa toho, ktorý peering VNet upravujete, takže čítajte smer, nie slovo. Nastavte obe strany, uložte a potvrďte, že peering hlási pripojenie na oboch miestach.
Tretia podmienka: adresný priestor a hranice oprávnení
Tranzit nemôže zabezpečiť, aby ten istý cieľový prefix znamenal dve siete, takže rozsahy hubu, spoke a lokálnej siete musia byť disjunktné, kým čokoľvek z toho začne fungovať. VNety môžu byť aj v rôznych predplatných alebo rôznych tenantoch; to nie je zákaz, ale identita, ktorá každý peering vytvára alebo aktualizuje, potrebuje na tejto sieti potrebné oprávnenia. Zmeny medzi predplatnými často zlyhávajú na oprávneniach a chybu možno ľahko nesprávne prečítať ako problém topológie.
Rozsahy a vlastníkov si pred zmenou zapíšte. Hádanie pri ktoromkoľvek z nich vedie k peeringu, ktorý sa pripojí a nič nesmeruje.
Overujte efektívnymi trasami, nie stavom peeringu
Pozrite sa na efektívne trasy na sieťovom rozhraní úlohy v spoke a nájdite skutočný prefix lokálnej siete. Skontrolujte smerovaciu tabuľku podsiete a či je vypnuté šírenie trás brány, pretože trasa definovaná používateľom alebo kontrolné zariadenie môže prepísať cestu, ktorú naznačujú príznaky peeringu. Potom potvrďte opačný smer: lokálna sieť musí vedieť, ako dosiahnuť prefix spoke cez pripojenie site-to-site, či už prostredníctvom naučených inzerátov, alebo explicitnou trasou a zodpovedajúcim záznamom chránenej siete na zariadení zákazníka. Ak prefix chýba na ktorejkoľvek strane, príznaky peeringu nie sú to, čo treba zmeniť.
Otestujte jednu službu z úlohy v spoke a sledujte odpoveď. Test z brány VPN alebo z VM v hube precvičuje iný zdrojový prefix a inú cestu.
Ak topológia obsluhuje aj klientov point-to-site, overte ich nainštalované trasy osobitne. Klientske balíčky Windows môžu po zmene topológie vyžadovať opätovné vygenerovanie, a to je úloha klientského smerovania, nie dôkaz, že zdieľanie brány zlyhalo.
Čo zdieľanie brány neposkytuje
Tranzit brány je smerovacie pohodlie, nie autorizácia. Skupiny zabezpečenia siete, lokálne filtre a pravidlá na úrovni služieb stále rozhodujú, kam môže úloha v spoke dosiahnuť, takže povoľte konkrétnu službu od zdroja k cieľu, namiesto toho, aby ste predpokladali, že zdieľaný tunel dovoľuje všetko za ním.
Peering tiež nie je tranzitívny tak, ako ľudia dúfajú. Pridanie ďalšieho spoke alebo privátneho koncového bodu prináša vlastné požiadavky na smerovanie a prístup, ktoré existujúce nastavenie tranzitu nepokrýva.