Azure VPN NAT lost overlappende VNet-adressen niet op
Twee VNetten met dezelfde privébereik verbinden niet zomaar omdat NAT bestaat. Controleer eerst het verbindingstype en hernummer daarna of bezit een vertaalalias.
Beide VNetten gebruiken 10.40.1.0/24, de tunnels komen omhoog en niets werkt. Een tweede VPN-gateway toevoegen verandert dat niet, en een lagere routemetriek ook niet, want het probleem is geen padselectie. Twee workloads die op hetzelfde privéadres antwoorden, laten elk pakket achter met een dubbelzinnige bestemming en een niet-verifieerbare retourweg. Voordat u enige vertaling plant, zoek uit welk verbindingstype u werkelijk hebt gemaakt, want die ene keuze bepaalt of de NAT-functie van Azure beschikbaar is.
Wat het symptoom u werkelijk vertelt
Wanneer een host in VNet A naar 10.40.1.10 stuurt, kan de routetabel hem alleen ergens naartoe wijzen. Als VNet B ook 10.40.1.10 bevat, is dat adres geen bestemming die het pad kan onderscheiden; het is één adres met twee eigenaren.
De tweede gateway die mensen gewoonlijk uitrollen helpt niet. Die geeft een andere tunnel, niet een ander adres, en het dubbele bereik reist onveranderd door de tunnel. Hij verdubbelt ook de configuratie die u consistent moet houden. Wat hij niet kan, is één adres twee hosts laten betekenen.
De openbare adressen van de VPN-peers wijzigen doet ook niets. Die adressen identificeren de tunneleindpunten, terwijl de botsing in het privébereik zit dat erbinnen wordt vervoerd.
Het verbindingstype bepaalt of NAT beschikbaar is
Azure VPN Gateway heeft wel een NAT-mogelijkheid, en die is gedocumenteerd voor routegebaseerde IPsec-verbindingen tussen locaties op specifieke gateway-SKU's. Dezelfde documentatie sluit VNet-naar-VNet- en point-to-site-verbindingen uit, dus de functie is geen selectievakje dat bij elke gateway-relatie verschijnt.
| 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 |
Native VNet-naar-VNet vereist ook dat de VNet- en lokale-netwerkbereiken vanaf het begin niet overlappen, wat in lijn is met de uitsluiting. VNet-peering is om dezelfde reden geen oplossing voor overlap.
Er is een ondersteund alternatief dat mensen met het native type verwarren: modelleer het andere VNet als lokaal netwerk en verbind het als locatie-naar-locatie. Dat is een andere resource en een ander ontwerp, dus behandel een hernoemde verbinding als een wijziging die gevalideerd moet worden, niet als een simpele naamswijziging.
Hernummer, of vertaal met iets dat de alias bezit
Als beide VNetten van u zijn, vergelijk dan een geplande hernummering met de doorlopende kosten van vertaling. Hernummering raakt applicatieconfiguratie, DNS-records, beveiligingsregels en elke bestaande verbinding, maar laat een netwerk achter dat daarna normaal leest. Doe het één subnet tegelijk, met de DNS-wijziging als laatste. Een half gehernummerd bereik is erger dan beide opties, omdat beide prefixen dan gezaghebbend lijken voor wie de tabel daarna leest.
Waar hernummering niet praktisch is, gebruik een vertaald ontwerp met een echte eigenaar voor de alias. Aanroepers in VNet A bereiken 10.40.1.10 van VNet B misschien als 10.140.1.10, maar die alias heeft een apparaat nodig dat vertaalt, een route ernaartoe en overeenkomstig gedrag voor het antwoord. Een adres dat alleen aan DNS is toegevoegd, is geen vertaling.
Leg beide bereiken in beide richtingen vast: wat de aanroeper kiest, wat de bestemming als bron ziet, en welke kant mag initiëren. De eigen NAT-regels van Azure bevatten de omgekeerde vertaling voor hun SNAT-mappings, dus u schrijft niet met de hand een overeenkomende DNAT-regel, maar dat gemak stopt bij de verbindingstypen die de functie ondersteunt.
Wat niet zal werken
Een door de gebruiker gedefinieerde route of een routemetriek kan geen ontbrekend adresonderscheid maken. Beide werken op een bestemming die nog steeds dubbelzinnig is, en het pakket komt aan bij de volgende hop die de tabel verkiest.
Het dubbele bereik als specifieker prefix aan een routetabel toevoegen verschuift de dubbelzinnigheid maar één stap. Het breekt ook vaak de andere richting, waar het antwoord nu twee plausibele bronnen heeft.
Accepteer het ontwerp met verkeer in beide richtingen
Bewijs het ontwerp met een verse toegestane bewerking van elke kant, niet met tunnelstatus. Een verbonden IPsec-tunnel zegt dat de peers het over cryptografie eens zijn; hij zegt niets over of de bestemmingen onderscheidbaar zijn geworden.
Voer daarna de geweigerde paden uit: een adres dat onbereikbaar moet blijven, en een dienst die het beleid moet blokkeren. Als beide nog steeds slagen, is de vertaling breder dan het ontwerp bedoelde.
Sluit af met de feiten die de opzet later verklaren: het oorspronkelijke bereik, het gepresenteerde bereik, het apparaat dat vertaalt, en de richting waarin elke kant mag initiëren. Als een daarvan ontbreekt, erft de volgende engineer een netwerk waarin twee hosts een naam delen en niemand zich herinnert waarom een van hen antwoordt.