Potřebuje Azure VNet propojená přes peering vlastní bránu VPN?

Objeví se nová spoke síť VNet, hub už má funkční bránu site-to-site a nasnadě je otázka, zda musíte platit za druhou bránu. Obvykle ne: tranzit brány umožňuje spoke síti využívat bránu hubu přes peering. O tom, zda to bude fungovat, rozhodují tři podmínky a žádnou z nich nevidíte na odznaku stavu peeringu. Připojení přes peering a oprávnění používat cizí bránu jsou samostatná nastavení, takže dva VM, které už na sebe umí pingovat, nic nedokazují o cestě VPN.

První podmínka: brána a její absence ve spoke síti

Azure podporuje tranzit brány pro skladové položky VPN Gateway jiné než Basic a unést ho může regionální i globální peering. Spoke spotřebovává bránu, kterou nevlastní, takže nemůže mít vlastní: pokud ve spoke už brána existuje nebo je už zvolena možnost vzdálené brány, nastavení tranzitu, které chcete, bude nedostupné nebo neúčinné. Ověřte to, než začnete cokoli ladit, protože zašedlé zaškrtávací pole je příznak, ne závada. Nejprve si přečtěte SKU a stávající bránu, teprve potom se podívejte na nastavení peeringu.

Nemažte existující bránu spoke sítě jen proto, aby se možnost objevila, dokud nevíte, co na ní závisí. Pořadí migrace je důležitější než zaškrtávací pole.

Druhá podmínka: jedno nastavení v každém směru peeringu

Peering jsou dva objekty, jeden na každé síti VNet, a nastavení tranzitu žijí na různých stranách této dvojice. Peering hubu směrem ke spoke musí bráně hubu dovolit obsluhovat spoke; peering spoke směrem k hubu musí bránu hubu přijmout. Průvodce tranzitem brány od Microsoftu je pojmenovává podle směru, což je jediný způsob, jak je udržet správně:

Ovládací prvek označený remote mění význam podle toho, čí peering upravujete, takže čtěte směr, ne slovo. Nastavte obě strany, uložte a potvrďte, že peering hlásí připojení na obou místech.

Třetí podmínka: adresní prostor a hranice oprávnění

Tranzit nemůže zajistit, aby stejný cílový prefix znamenal dvě sítě, takže rozsahy hubu, spoke a lokální sítě musí být disjunktní, než cokoli z toho začne fungovat. Sítě VNet mohou být také v různých předplatných nebo různých tenantech; to není zákaz, ale identita, která každý peering vytváří nebo aktualizuje, potřebuje na dané síti příslušná oprávnění. Změny mezi předplatnými často selhávají na oprávněních a chybu lze snadno mylně číst jako problém topologie.

Rozsahy a vlastníky si před změnou zapište. Hádání u kteréhokoli z nich vede k peeringu, který se připojí a nic nesměruje.

Ověřujte efektivními trasami, ne stavem peeringu

Podívejte se na efektivní trasy na síťovém rozhraní úlohy ve spoke a najděte skutečný prefix lokální sítě. Zkontrolujte směrovací tabulku podsítě a zda je vypnuté šíření tras brány, protože trasa definovaná uživatelem nebo inspekční zařízení může přepsat cestu, kterou naznačují příznaky peeringu. Potom potvrďte opačný směr: lokální síť musí vědět, jak dosáhnout prefixu spoke přes připojení site-to-site, ať už prostřednictvím naučených inzerátů, nebo explicitní trasou a odpovídajícím záznamem chráněné sítě na zařízení zákazníka. Chybí-li prefix na kterékoli straně, nejsou příznaky peeringu to, co je třeba změnit.

Vyzkoušejte jednu službu z úlohy ve spoke a sledujte odpověď. Test z brány VPN nebo z VM v hubu procvičuje jiný zdrojový prefix a jinou cestu.

Pokud topologie obsluhuje i klienty point-to-site, ověřte jejich nainstalované trasy zvlášť. Klientské balíčky Windows mohou po změně topologie vyžadovat opětovné vygenerování, a to je úkol klientského směrování, nikoli důkaz, že sdílení brány selhalo.

Co sdílení brány neposkytuje

Tranzit brány je směrovací pohodlí, ne autorizace. Skupiny zabezpečení sítě, lokální filtry a pravidla na úrovni služeb stále rozhodují o tom, kam může úloha ve spoke dosáhnout, takže povolte konkrétní službu od zdroje k cíli, místo abyste předpokládali, že sdílený tunel dovoluje vše za ním.

Peering také není tranzitivní tak, jak lidé doufají. Přidání další spoke nebo privátního koncového bodu přináší vlastní požadavky na směrování a přístup, které stávající nastavení tranzitu nepokrývá.