Azure VPN NAT léist net iwwerlappend VNet-Adressen
Zwee VNet mat dem selwechte private Beräich verbannen sech net just well NAT do ass. Kontrolléiert éischt den Typ vun der Verbindung an dann enumeréiert nei oder besëtzt en Iwwersetzungsalias.
Béid VNet benotzen 10.40.1.0/24, d'Tunnele kommen erop, an näischt funktionnéiert. En zweeten VPN-Gateway derbäisetzen ännert dat net, an eng méi niddereg Routemetrik och net, well de Problem net d'Path-Wiel ass. Zwee Workloaden, déi op déiselwecht privat Adress äntweren, loosse jiddereen Paket mat enger onklarer Destinatioun an engem net iwwerpréifbare Réckwee. Ier dir eng Iwwersetzung plangt, fannt eraus wéi en Typ vun Verbindung dir tatsächlech erstallt hutt, well dës eenzeg Wiel entscheet ob d'NAT-Funktioun vum Azure iwwerhaapt disponibel ass.
Wat d'Symptom Iech wierklech seet
Wann e Host an VNet A op 10.40.1.10 schéckt, kann d'Routingstabell en just irgendwou hinnermeelen. Wann VNet B och 10.40.1.10 enthält, ass déi Adress keng Destinatioun déi de Path ënnerscheede kann; et ass eng Adress mat zwee Besëtzer.
Den zweeten Gateway, deen d'Leit normalerweis asetzen, hëlleft net. En gëtt Iech en aneren Tunnel, net eng aner Adress, an dee duebelte Beräich reest onverännert am Tunnel. En duebelt och d'Konfiguratioun déi dir konsequent muss halen. Wat en net kann, ass eng Adress zwee Hosten heeschen ze loossen.
D'ëffentlech Adresse vun de VPN-Peers z'änneren mécht och näischt. Déi Adressen identifizéieren d'Ennpunkte vum Tunnel, während d'Kollisioun am private Beräich läit, deen dobannen transportéiert gëtt.
Den Typ vun der Verbindung entscheet ob NAT disponibel ass
Azure VPN Gateway huet tatsächlech eng NAT-Beruffung, an se ass dokumentéiert fir routebaséiert IPsec-Verbindungen tëschent Siten op spezifesche Gateway-SKUen. Déiselwecht Dokumentatioun schléisst VNet-to-VNet- a point-to-site-Verbindungen aus, also ass d'Funktioun keng Këscht fir ofzehaken déi op all Gateway-Relatioun erschéngt.
| 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-to-VNet erfuerdert och datt d'VNet- a lokale-Netzwierk-Beräicher vun Ufank un net iwwerlappen, wat mat der Ausnam iwwerenee stëmmt. VNet-Peering ass aus dem selwechte Grond keng Léisung fir Iwwerlappung.
Et gëtt eng ënnerstëtzt Alternativ déi d'Leit mam native Typ verwiesselen: modelléiert dat anert VNet als lokalen Netzwierk an verbënnt et als Site-zu-Site-Verbindung. Dat ass eng aner Ressource an en aneren Design, also behandelt eng ëmbenannte Verbindung als Ännerung déi muss validéiert ginn, net als bloos Ëmbenennung.
Enumeréiert nei, oder iwwersetzt mat eppes wat den Alias besëtzt
Wann béid VNet Är sinn, vergläicht eng geplangt Nei-Enumeréierung mat de lafende Käschte vun der Iwwersetzung. D'Nei-Enumeréierung beréiert Applikatiounskonfiguratioun, DNS-Andräg, Sécherheetsregelen an all existéierend Verbindung, awer léisst en Netzwierk zréck dat duerno normal gelies gëtt. Maacht et ee Subnet op eemol, mat der DNS-Ännerung als lescht. En hallef nei enumeréierte Beräich ass schlëmmer wéi béid Optiounen, well dann zwou Präfixe fir deen nächsten deen d'Tabell liest autoritär ausgesinn.
Wou d'Nei-Enumeréierung net praktesch ass, benotzt en iwwersat Design mat engem richtegen Besëtzer fir den Alias. Opruffer an VNet A erreechen 10.40.1.10 vun VNet B vläicht als 10.140.1.10, awer deen Alias brauch en Apparat deen iwwersetzt, eng Route dohinner an eng passend Verhalen fir d'Äntwert. Eng Adress déi nëmmen an DNS bäigefüügt gëtt ass keng Iwwersetzung.
Hält béid Beräicher a béid Richtungen fest: wat den Opruffer wielt, wat d'Destinatioun als Quell gesäit, a wéi eng Säit initiéiere kann. Dem Azure seng eegen NAT-Reegelen enthalen d'Réckiwwersetzung fir hir SNAT-Mappungen, also schreift dir keng passend DNAT-Reeg vun Hand, awer dëse Komfort hält bei de Verbindungstypen op déi d'Funktioun ënnerstëtzt.
Wat net funktionéiere wäert
Eng benotzerdefinéiert Route oder eng Routemetrik kann eng feelend Adressënnerscheedung net schafen. Béid schaffen op enger Destinatioun déi nach ëmmer onklar ass, an de Paket kënnt bei deem nächsten Hop un deen d'Tabell bevorzugt.
Den duebelte Beräich als méi spezifesche Präfix an eng Routingstabell opzehuelen versetz d'Onkloerheet nëmmen ee Schrëtt. Et brécht och dacks déi aner Richtung, wou d'Äntwert elo zwee plausibel Quelle huet.
Akzeptéiert den Design mat Traffic a béid Richtungen
Beweist den Design mat enger frëscher erlaabter Operatioun vun all Säit, net mam Tunnelstatus. En verbonnenen IPsec-Tunnel seet datt d'Peers sech iwwer Krypto eens sinn; en seet näischt doriwwer ob d'Destinatiounen ënnerscheedbar ginn sinn.
Führt dann déi refuséiert Weeër aus: eng Adress déi onerrechbar bleiwe soll, an e Service deen d'Politik soll blockéieren. Wann béid nach ëmmer geléngt, ass d'Iwwersetzung méi breet wéi den Design geduecht hat.
Schléisst mat de Fakten of déi de Setup méi spéit erklären: de urspréngleche Beräich, dee presentéierte Beräich, den Apparat deen iwwersetzt, an d'Richtung an déi all Säit initiéiere kann. Wann ee vun deene feelt, ierft den nächsten Ingenieur en Netzwierk wou zwee Hosten en Numm deelen an keen sech drun erënnert firwat een vun hinnen äntwert.