NAT na Azure VPN nevyřeší překrývající se adresy VNet
Dvě VNet se stejným privátním rozsahem se nepřipojí jen proto, že existuje NAT. Nejprve zkontrolujte typ připojení a potom přečíslujte, nebo vlastněte překladový alias.
Obě VNet používají 10.40.1.0/24, tunely se zvednou a nic nefunguje. Přidání druhého VPN gateway to nezmění, a ani nižší metrika trasy, protože problém není ve výběru cesty. Dvě úlohy odpovídající na stejnou privátní adresu nechávají každý paket s nejednoznačným cílem a neověřitelnou zpáteční cestou. Než naplánujete jakýkoli překlad, zjistěte, jaký typ připojení jste skutečně vytvořili, protože tato jediná volba rozhoduje o tom, zda je funkce NAT v Azure vůbec dostupná.
Co vám ten příznak vlastně říká
Když host v VNet A odešle na 10.40.1.10, směrovací tabulka ho může jen někam nasměrovat. Pokud VNet B také obsahuje 10.40.1.10, tato adresa není cíl, který by cesta dokázala rozlišit; je to jedna adresa se dvěma vlastníky.
Druhý gateway, který lidé obvykle nasazují, nepomůže. Dá vám další tunel, ne další adresu, a duplicitní rozsah putuje uvnitř tunelu beze změny. Také zdvojnásobuje konfiguraci, kterou musíte udržovat konzistentní. Co nedokáže, je zařídit, aby jedna adresa znamenala dva hosty.
Změna veřejných adres VPN protějšků také nic neudělá. Tyto adresy určují koncové body tunelu, zatímco kolize je v privátním rozsahu přenášeném uvnitř.
Typ připojení rozhoduje o tom, zda je NAT dostupný
Azure VPN Gateway skutečně má schopnost NAT a ta je zdokumentována pro mezisíťová připojení IPsec založená na trasách u konkrétních SKU brány. Stejná dokumentace vylučuje připojení VNet-to-VNet a point-to-site, takže to není zaškrtávací políčko, které se objeví u každého vztahu brány.
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
Nativní VNet-to-VNet také vyžaduje, aby se rozsahy VNet a místní sítě od počátku nepřekrývaly, což je v souladu s vyloučením. VNet peering není řešením překryvu ze stejného důvodu.
Existuje podporovaná alternativa, kterou si lidé pletou s nativním typem: namodelujte druhou VNet jako místní síť a připojte ji jako spojení mezi lokalitami. To je jiný prostředek a jiný návrh, takže přejmenované připojení berte jako změnu, kterou je třeba ověřit, ne jako pouhý přepis názvu.
Přečíslujte, nebo překládejte s něčím, co alias vlastní
Pokud jsou obě VNet vaše, porovnejte plánované přečíslování s průběžnými náklady na překlad. Přečíslování se dotkne konfigurace aplikací, záznamů DNS, bezpečnostních pravidel a každého existujícího připojení, ale zanechá síť, která se potom čte normálně. Dělejte to po jedné podsíti, se změnou DNS nakonec. Napůl přečíslovaný rozsah je horší než kterákoli varianta, protože pak oba prefixy vypadají autoritativně pro toho, kdo tabulku příště přečte.
Kde přečíslování není praktické, použijte přeložený návrh se skutečným vlastníkem aliasu. Volající ve VNet A se mohou dostat na 10.40.1.10 ve VNet B jako na 10.140.1.10, ale tento alias potřebuje zařízení, které překládá, trasu k němu a odpovídající chování pro odpověď. Adresa přidaná jen do DNS není překlad.
Zaznamenejte oba rozsahy v obou směrech: co volající vytáčí, co cíl vidí jako zdroj a která strana může iniciovat. Vlastní pravidla NAT v Azure zahrnují zpětný překlad pro svá mapování SNAT, takže odpovídající pravidlo DNAT nepíšete ručně, ale tato výhoda končí u typů připojení, které funkce podporuje.
Co nebude fungovat
Uživatelsky definovaná trasa ani metrika trasy nedokážou vytvořit chybějící rozlišení adres. Obě působí na cíl, který je stále nejednoznačný, a paket dorazí na další skok, který tabulka preferuje.
Přidání duplicitního rozsahu do směrovací tabulky jako konkrétnějšího prefixu posune nejednoznačnost jen o krok. Také má tendenci rozbít opačný směr, kde má odpověď nyní dva pravděpodobné zdroje.
Přijměte návrh s provozem v obou směrech
Dokažte návrh čerstvou povolenou operací z každé strany, ne stavem tunelu. Připojený tunel IPsec říká, že se protějšky shodují na kryptografii; neříká nic o tom, zda se cíle staly rozlišitelnými.
Potom spusťte zakázané cesty: adresu, která má zůstat nedostupná, a službu, kterou má politika blokovat. Pokud obojí stále uspěje, je překlad širší, než návrh zamýšlel.
Uzavřete to fakty, které později vysvětlí nastavení: původní rozsah, prezentovaný rozsah, zařízení, které překládá, a směr, kterým každá strana může iniciovat. Pokud některý chybí, následující inženýr dědí síť, kde dva hosty sdílejí jméno a nikdo si nepamatuje, proč jeden z nich odpovídá.