UDR v Azure k bráně VPN: jeden cíl, ne veškerý odchozí provoz

Nasměrujte jeden prefix Azure na bránu VPN, aniž byste přesunuli veškerý odchozí provoz. Přečtěte efektivní trasy, připojte podsíť úlohy a dokončete cestu zpět.

Přidáte uživatelem definovanou trasu pro jeden externí prefix, nasměrujete ji na bránu VPN a provoz stejně odchází internetovou cestou Azure. Nebo odchází správně a odpověď se nikdy nevrátí. Oba výsledky pocházejí ze stejné chyby: považovat další skok v Azure za celý návrh. Tabulka tras rozhoduje jen o tom, kterým výstupem paket v Azure odejde. Co se s ním stane po tunelu a jak se vrátí odpověď, je druhá polovina, kterou musíte postavit.

Další skok je brána, ne IP adresa zařízení

UDR posílá odpovídající prefix typu dalšího skoku a VirtualNetworkGateway je typ, nikoli adresa. Lidé vloží privátní IP brány do trasy VirtualAppliance a pak se diví, proč nic neodpovídá, protože tento typ očekává síťovou kartu nebo interní load balancer. Dokumentace Microsoftu ke směrování také omezuje další skok brány na virtuální síť, jejíž brána je bránou VPN. ExpressRoute, Route Server a hub Virtual WAN touto možností adresovat nelze.

Než trasu napíšete, ověřte, co virtuální síť skutečně má. Pokud návrh směruje přes hub, trasa patří vlastníkovi směrování hubu, ne spoku, který zrovna upravujete.

Přečtěte si efektivní trasu, než cokoli změníte

Azure slučuje systémové trasy, prefixy naučené přes BGP a UDR do efektivní tabulky tras pro každou síťovou kartu a nejdelší odpovídající prefix vyhrává bez ohledu na původ. Pro stejný prefix UDR poráží trasu BGP. Kvůli tomuto pořadí může starý UDR z dřívějšího experimentu tiše přebít prefix, který jste právě poznali tunelem.

Podívejte se nejprve na efektivní tabulku a pak rozhodněte, zda trasu přidáváte, nebo nahrazujete:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

Čtěte i sloupec zdroje, ne jen prefix. Trasa se správným prefixem a špatným zdrojem vám řekne, který objekt upravit, a ušetří vás přidání druhé trasy, která prohraje s první.

Napište trasu podle skutečného prefixu a podsítě

Použijte skutečný prefix cíle převzatý ze služby, na kterou opravdu dosahujete, místo veřejného rozsahu zkopírovaného z příspěvku na fóru. Začněte jednou schválenou službou, než zvážíte výchozí trasu, která přesune veškerý odchozí provoz. Potom připojte tabulku tras k podsíti úlohy. Podsíť brány má své vlastní požadavky a připojení vaší tabulky tam bránu rozbije, místo aby směrovalo úlohu.

Vytvořte trasu a potom připojte tabulku k podsíti, která hostuje úlohu:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

Záleží i na propagaci. Když je na této tabulce povolena propagace BGP, naučené prefixy se objeví vedle těch, které jste napsali, a konkrétnější naučený prefix může porazit širší UDR. Propagaci vypněte jen tehdy, když chcete, aby množina UDR byla pro tuto podsíť autoritativní.

Dokončete lokální polovinu, jinak tok tam zemře

Lokální brána musí přijmout zdroj z Azure, předat ho cíli a povolit aplikaci. Její další cesta může být internetový výstup nebo jiný privátní skok, ale toto rozhodnutí patří do plánu, ne do tabulky tras Azure. Obvyklou poruchou je návrat. Internetový cíl nebude směrovat privátní zdroj z Azure zpět k vám, takže odpověď jde na svou výchozí bránu a zemře, nebo vůbec neodejde.

Dva návrhy to řeší a nejsou zaměnitelné. Přeložte zdroj na výstupu, aby cíl odpovídal na veřejnou adresu, kterou lokální síť vlastní. Nebo zdroj zachovejte a postavte směrovaný vztah pro návrat, aby se odpovědi vracely tunelem. Vyberte jedno a zapište, kterou adresu aplikace uvidí.

Selektory a seznamy povolených jsou od toho všeho oddělené. Volba dalšího skoku v Azure nerozšiřuje selektory provozu VPN a nemění seznam povolených zdrojů externí služby.

Ověřte podle zdroje, který cíl vidí

Pošlete požadavek ze skutečné úlohy, ne z odrazového hostitele v jiné podsíti, a pak přečtěte zdrojovou adresu, kterou cíl pozoroval. Tato jediná hodnota vám řekne, který ze dvou návrhů návratu je nasazen. Potom zkontrolujte cestu odpovědi a potvrďte, že běžný provoz správy k virtuálnímu počítači stále funguje, protože výchozí trasa přidaná omylem se projeví jako rozbitá relace SSH mnohem dřív než jako rozbitá aplikace.

Tranzit přes vybraný prefix je mnohem užší změna než vynucené tunelování. Udržte ho úzký a vrácení zpět znamená smazat jednu trasu.

Související články