Az Azure VPN NAT-ja nem oldja meg az átfedő VNet-címeket
Két azonos privát tartományú VNet nem fog összekapcsolódni csak azért, mert létezik NAT. Először ellenőrizze a kapcsolat típusát, majd számozza újra, vagy birtokoljon fordítási aliast.
Mindkét VNet a 10.40.1.0/24 tartományt használja, az alagutak feljönnek, és semmi sem működik. Egy második VPN-átjáró hozzáadása nem változtat ezen, és egy alacsonyabb útvonal-metrika sem, mert a probléma nem az útvonalválasztás. Két számítási feladat, amely ugyanarra a privát címre válaszol, minden csomagot kétértelmű céllal és ellenőrizhetetlen visszaúttal hagy. Bármilyen fordítás tervezése előtt derítse ki, milyen kapcsolattípust hozott létre valójában, mert ez az egyetlen választás dönti el, hogy az Azure NAT-funkciója egyáltalán elérhető-e.
Mit mond el valójában a tünet
Amikor a VNet A egyik gazdagépe a 10.40.1.10 címre küld, az útválasztási táblázat csak valahova irányíthatja. Ha a VNet B is tartalmazza a 10.40.1.10 címet, az a cím nem olyan cél, amelyet az útvonal meg tudna különböztetni; ez egy cím két tulajdonossal.
A második átjáró, amelyet az emberek általában telepítenek, nem segít. Egy másik alagutat ad, nem másik címet, és a duplikált tartomány változatlanul utazik az alagúton belül. Ez megduplázza a konfigurációt is, amelyet egységesen kell tartania. Amit nem tud, az az, hogy egy cím két gazdagépet jelentsen.
A VPN-társak nyilvános címeinek módosítása sem tesz semmit. Azok a címek azonosítják az alagút végpontjait, míg az ütközés az abban szállított privát tartományban van.
A kapcsolat típusa dönti el, elérhető-e a NAT
Az Azure VPN Gateway valóban rendelkezik NAT-képességgel, és ez dokumentált az útvonalalapú IPsec telephelyek közötti kapcsolatokhoz bizonyos átjáró-SKU-kon. Ugyanez a dokumentáció kizárja a VNet-to-VNet és a point-to-site kapcsolatokat, tehát a funkció nem egy jelölőnégyzet, amely minden átjáró-kapcsolatnál megjelenik.
| 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 |
A natív VNet-to-VNet azt is megköveteli, hogy a VNet és a helyi hálózat tartománya kezdettől ne fedje át egymást, ami összhangban van a kizárással. A VNet-társítás ugyanezen okból nem megoldás az átfedésre.
Van egy támogatott alternatíva, amelyet az emberek összekevernek a natív típussal: modellezze a másik VNetet helyi hálózatként, és csatlakoztassa telephelyek közötti kapcsolatként. Ez más erőforrás és más tervezés, ezért az átnevezett kapcsolatot érvényesítendő változásnak tekintse, ne puszta átnevezésnek.
Számozza újra, vagy fordítson olyasmivel, amely birtokolja az aliast
Ha mindkét VNet az Öné, hasonlítsa össze a tervezett újraszámozást a fordítás folyamatos költségével. Az újraszámozás érinti az alkalmazáskonfigurációt, a DNS-rekordokat, a biztonsági szabályokat és minden meglévő kapcsolatot, de olyan hálózatot hagy maga után, amely utána normálisan olvasható. Egyenként végezze alhálózatonként, a DNS-változtatással a végén. A félig újraszámozott tartomány rosszabb mindkét lehetőségnél, mert akkor mindkét előtag hitelesnek tűnik annak, aki legközelebb olvassa a táblázatot.
Ahol az újraszámozás nem praktikus, használjon fordított tervezést valódi tulajdonossal az alias számára. A VNet A hívói elérhetik a VNet B 10.40.1.10 címét 10.140.1.10 címként, de ehhez az aliashez fordító eszköz, felé vezető útvonal és a válaszhoz illeszkedő viselkedés kell. A csak DNS-hez hozzáadott cím nem fordítás.
Rögzítse mindkét tartományt mindkét irányban: mit tárcsáz a hívó, mit lát a cél forrásként, és melyik fél kezdeményezhet. Az Azure saját NAT-szabályai tartalmazzák a fordított fordítást SNAT-leképezéseikhez, tehát nem ír kézzel megfelelő DNAT-szabályt, de ez a kényelem a funkció által támogatott kapcsolattípusoknál véget ér.
Mi nem fog működni
A felhasználó által meghatározott útvonal vagy útvonal-metrika nem hozhat létre hiányzó címbeli megkülönböztetést. Mindkettő még mindig kétértelmű célon működik, és a csomag ahhoz a következő ugráshoz érkezik, amelyet a táblázat előnyben részesít.
A duplikált tartomány felvétele egy útválasztási táblázatba pontosabb előtagként csak egy lépéssel mozdítja el a kétértelműséget. Általában a másik irányt is elrontja, ahol a válasznak most két valószínű forrása van.
Fogadja el a tervezést mindkét irányú forgalommal
Bizonyítsa a tervezést friss engedélyezett művelettel mindkét oldalról, nem az alagút állapotával. Egy csatlakoztatott IPsec-alagút azt mondja, hogy a társak egyetértenek a titkosításban; semmit sem mond arról, hogy a célok megkülönböztethetővé váltak-e.
Ezután futtassa a tiltott útvonalakat: egy címet, amelynek elérhetetlennek kell maradnia, és egy szolgáltatást, amelyet a szabályzatnak blokkolnia kell. Ha mindkettő továbbra is sikeres, a fordítás szélesebb a tervezettnél.
Zárja a telepítést később megmagyarázó tényekkel: az eredeti tartomány, a bemutatott tartomány, a fordító eszköz és az irány, amelyben mindkét fél kezdeményezhet. Ha ezek bármelyike hiányzik, a következő mérnök olyan hálózatot örököl, ahol két gazdagép osztozik egy néven, és senki sem emlékszik, miért válaszol az egyik.