NAT v Azure VPN nerieši prekrývajúce sa adresy VNet
Dve VNet s rovnakým privátnym rozsahom sa neprepoja len preto, že existuje NAT. Najprv skontrolujte typ pripojenia, potom prečíslujte alebo vlastnite prekladový alias.
Obe VNet používajú 10.40.1.0/24, tunely sa zdvihnú a nič nefunguje. Pridanie druhého VPN gatewayu to nezmení, ani nižšia metrika trasy, pretože problém nie je vo výbere cesty. Dve úlohy, ktoré odpovedajú na rovnakú privátnu adresu, nechávajú každý paket s nejednoznačným cieľom a neoveriteľnou spiatočnou cestou. Skôr než naplánujete akýkoľvek preklad, zistite, aký typ pripojenia ste skutočne vytvorili, pretože tá jediná voľba rozhoduje o tom, či je funkcia NAT v Azure vôbec dostupná.
Čo vám ten príznak vlastne hovorí
Keď host v VNet A odošle na 10.40.1.10, smerovacia tabuľka ho môže len niekam nasmerovať. Ak VNet B tiež obsahuje 10.40.1.10, tá adresa nie je cieľ, ktorý by cesta vedela rozlíšiť; je to jedna adresa s dvoma vlastníkmi.
Druhý gateway, ktorý ľudia zvyčajne nasadzujú, nepomáha. Dáva ďalší tunel, nie ďalšiu adresu, a duplicitný rozsah cestuje v tuneli bez zmeny. Tiež zdvojnásobuje konfiguráciu, ktorú musíte udržiavať konzistentnú. Čo nedokáže, je spôsobiť, aby jedna adresa znamenala dvoch hostov.
Zmena verejných adries VPN partnerov tiež nič neprináša. Tie adresy určujú koncové body tunela, zatiaľ čo kolízia je v privátnom rozsahu prenášanom vnútri.
Typ pripojenia rozhoduje o tom, či je NAT dostupný
Azure VPN Gateway skutočne má schopnosť NAT a tá je zdokumentovaná pre medzisietové pripojenia IPsec založené na trasách na konkrétnych SKU brány. Tá istá dokumentácia vylučuje pripojenia VNet-to-VNet a point-to-site, takže to nie je zaškrtávacie pole, ktoré sa objaví pri každom vzťahu 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 |
Natívne VNet-to-VNet tiež vyžaduje, aby sa rozsahy VNet a miestnej siete od začiatku neprekrývali, čo je v súlade s vylúčením. VNet peering nie je riešením prekrývania z rovnakého dôvodu.
Existuje podporovaná alternatíva, ktorú si ľudia mýlia s natívnym typom: namodelujte druhú VNet ako miestnu sieť a pripojte ju ako spojenie medzi lokalitami. To je iný prostriedok a iný návrh, takže premenované pripojenie berte ako zmenu, ktorú treba overiť, nie ako obyčajné premenovanie.
Prečíslujte alebo prekladajte niečím, čo alias vlastní
Ak sú obe VNet vaše, porovnajte plánované prečíslovanie s priebežnými nákladmi na preklad. Prečíslovanie sa dotkne konfigurácie aplikácií, záznamov DNS, bezpečnostných pravidiel a každého existujúceho pripojenia, ale zanechá sieť, ktorá sa potom číta normálne. Robte to po jednej podsieti, so zmenou DNS nakoniec. Na polovicu prečíslovaný rozsah je horší než ktorákoľvek možnosť, pretože potom oba prefixy vyzerajú autoritatívne pre toho, kto tabuľku nabudúce prečíta.
Tam, kde prečíslovanie nie je praktické, použite preložený návrh so skutočným vlastníkom aliasu. Volajúci vo VNet A sa môžu dostať na 10.40.1.10 vo VNet B ako na 10.140.1.10, ale tento alias potrebuje zariadenie, ktoré prekladá, trasu k nemu a zodpovedajúce správanie pre odpoveď. Adresa pridaná len do DNS nie je preklad.
Zaznamenajte oba rozsahy v oboch smeroch: čo volajúci vytáča, čo cieľ vidí ako zdroj a ktorá strana môže iniciovať. Vlastné pravidlá NAT v Azure zahŕňajú spätný preklad pre svoje mapovania SNAT, takže zodpovedajúce pravidlo DNAT nepíšete ručne, ale táto výhoda sa končí pri typoch pripojení, ktoré funkcia podporuje.
Čo nebude fungovať
Používateľom definovaná trasa ani metrika trasy nedokážu vytvoriť chýbajúce rozlíšenie adries. Obe pôsobia na cieľ, ktorý je stále nejednoznačný, a paket dorazí na ďalší skok, ktorý tabuľka uprednostňuje.
Pridanie duplicitného rozsahu do smerovacej tabuľky ako konkrétnejšieho prefixu posunie nejednoznačnosť len o krok. Tiež má tendenciu rozbiť opačný smer, kde má odpoveď teraz dva pravdepodobné zdroje.
Prijmite návrh s prevádzkou v oboch smeroch
Dokážte návrh čerstvou povolenou operáciou z každej strany, nie stavom tunela. Pripojený tunel IPsec hovorí, že partneri sa zhodujú na kryptografii; nehovorí nič o tom, či sa ciele stali rozlíšiteľnými.
Potom spustite zakázané cesty: adresu, ktorá má zostať nedostupná, a službu, ktorú má politika blokovať. Ak obe stále uspejú, preklad je širší, než návrh zamýšľal.
Uzavrite faktami, ktoré neskôr vysvetlia nastavenie: pôvodný rozsah, prezentovaný rozsah, zariadenie, ktoré prekladá, a smer, v ktorom môže každá strana iniciovať. Ak niečo z toho chýba, nasledujúci inžinier zdedí sieť, kde dvaja hostia zdieľajú meno a nikto si nepamätá, prečo jeden z nich odpovedá.