Azure VPN NAT los nie oorvleuelende VNet-adresse op nie
Twee VNets met dieselfde private reeks sal nie net omdat NAT bestaan aan mekaar koppel nie. Kyk eers na die verbindingstipe en hernommer dan, of besit self die vertalingsalias.
Albei VNets gebruik 10.40.1.0/24, die tonnels kom op, en niks werk nie. Om 'n tweede VPN-gateway by te voeg verander dit nie, en 'n laer roetemetriek ook nie, want die probleem is nie padkeuse nie. Twee werkladinge wat op dieselfde private adres antwoord, laat elke pakkie met 'n onduidelike bestemming en 'n onverifieerbare terugpad. Voordat jy enige vertaling beplan, moet jy uitvind watter verbindingstipe jy werklik geskep het, want daardie enkele keuse besluit of Azure se NAT-funksie hoegenaamd beskikbaar is.
Wat die simptoom jou eintlik sê
Wanneer 'n gasheer in VNet A na 10.40.1.10 stuur, kan die roetetabel dit net êrens heen wys. As VNet B ook 10.40.1.10 bevat, is daardie adres nie 'n bestemming wat die pad kan onderskei nie; dit is een adres met twee eienaars.
Die tweede gateway wat mense gewoonlik ontplooi, help nie. Dit gee jou nog 'n tonnel, nie nog 'n adres nie, en die duplikaatreëls reis onveranderd binne die tonnel. Dit verdubbel ook die konfigurasie wat jy konsekwent moet hou. Wat dit nie kan doen nie, is om een adres twee gashere te laat beteken.
Om die publieke adresse van die VPN-eweknieë te verander, doen ook niks. Daardie adresse identifiseer die tonnel-eindpunte, terwyl die botsing in die private reeks binne-in dit lê.
Die verbindingstipe bepaal of NAT beskikbaar is
Azure VPN Gateway het wel 'n NAT-vermoë, en dit is gedokumenteer vir roetegebaseerde IPsec-verbindings tussen persele op spesifieke gateway-SKU's. Dieselfde dokumentasie sluit VNet-tot-VNet- en punt-tot-punt-verbindings uit, so die funksie is nie 'n merkie wat op elke gateway-verhouding verskyn nie.
| 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 |
Inheemse VNet-tot-VNet vereis ook dat die VNet- en plaaslike-netwerkreekse van meet af aan nie oorvleuel nie, wat met die uitsluiting ooreenstem. VNet-peering is om dieselfde rede nie 'n oplossing vir oorvleueling nie.
'n Ondersteunde alternatief wat mense met die inheemse tipe verwar, bestaan: modelleer die ander VNet as 'n plaaslike netwerk en koppel dit as 'n werf-tot-werf-verbinding. Dit is 'n ander hulpbron en 'n ander ontwerp, so behandel 'n herbenoemde verbinding as 'n verandering wat gevalideer moet word, nie as 'n naamverandering nie.
Hernommer, of vertaal met iets wat die alias besit
As albei VNets joune is, vergelyk 'n beplande hernommering met die deurlopende koste van vertaling. Hernommering raak toepassingkonfigurasie, DNS-rekords, sekuriteitsreëls en elke bestaande verbinding, maar dit laat 'n netwerk wat daarna normaal lees. Doen dit een subnet op 'n slag, met die DNS-verandering laaste. 'n Half-hernommerde reeks is slegter as enige van die twee opsies, want albei voorvoegsels lyk dan gesaghebbend vir wie volgende die tabel lees.
Waar hernommering nie prakties is nie, gebruik 'n vertaalde ontwerp met 'n werklike eienaar vir die alias. Oproepers in VNet A bereik dalk VNet B se 10.40.1.10 as 10.140.1.10, maar daardie alias het 'n toestel nodig wat vertaal, 'n pad daarheen, en ooreenstemmende gedrag vir die antwoord. 'n Adres wat net by DNS gevoeg is, is nie 'n vertaling nie.
Teken albei reekse in albei rigtings aan: wat die oproeper skakel, wat die bestemming as die bron sien, en watter kant mag inisieer. Azure se eie NAT-reëls sluit die omgekeerde vertaling vir hulle SNAT-afbeeldings in, so jy skryf nie met die hand 'n ooreenstemmende DNAT-reël nie, maar daardie gerief stop by die verbindingstipes wat die funksie ondersteun.
Wat nie sal werk nie
'n Gebruiker-gedefinieerde roete of 'n roetemetriek kan nie 'n ontbrekende adresonderskeid skep nie. Albei werk op 'n bestemming wat steeds onduidelik is, en die pakkie kom by watter volgende sprong die tabel ook al verkies.
Om die duplikaatreëls as 'n meer spesifieke voorvoegsel by 'n roetetabel te voeg, skuif die onduidelikheid net een stap. Dit is ook geneig om die ander rigting te breek, waar die antwoord nou twee geloofwaardige bronne het.
Aanvaar die ontwerp met verkeer in albei rigtings
Bewys die ontwerp met 'n vars toegelate bewerking van elke kant, nie met tonnelstatus nie. 'n Gekoppelde IPsec-tonnel sê die eweknieë stem oor kripto saam; dit sê niks oor of die bestemmings onderskeibaar geword het nie.
Voer dan die geweierde paaie uit: 'n adres wat onbereikbaar moet bly, en 'n diens wat die beleid moet blokkeer. As albei steeds slaag, is die vertaling wyer as wat die ontwerp bedoel het.
Sluit af met die feite wat die opstelling later verduidelik: die oorspronklike reeks, die aangebode reeks, die toestel wat vertaal, en die rigting wat elke kant mag inisieer. As enige van dié ontbreek, erf die volgende ingenieur 'n netwerk waar twee gashere 'n naam deel en niemand onthou hoekom een van hulle antwoord nie.