El NAT d'Azure VPN no resol les adreces VNet superposades
Dues VNet amb el mateix rang privat no es connectaran només perquè existeixi NAT. Reviseu primer el tipus de connexió i després renumereu o tingueu un àlies de traducció.
Totes dues VNet fan servir 10.40.1.0/24, els túnels s'aixequen i no funciona res. Afegir una segona passarel·la VPN no ho canvia, i una mètrica de ruta més baixa tampoc, perquè el problema no és la selecció de camí. Dues càrregues de treball que responen a la mateixa adreça privada deixen cada paquet amb una destinació ambigua i un camí de tornada no verificable. Abans de planificar qualsevol traducció, esbrineu quin tipus de connexió heu creat realment, perquè aquesta única elecció decideix si la funció NAT d'Azure està disponible o no.
Què us està dient realment el símptoma
Quan un amfitrió de la VNet A envia a 10.40.1.10, la taula d'encaminament només el pot apuntar en algun lloc. Si la VNet B també conté 10.40.1.10, aquesta adreça no és una destinació que el camí pugui distingir; és una adreça amb dos propietaris.
La segona passarel·la que la gent sol desplegar no ajuda. Us dona un altre túnel, no una altra adreça, i el rang duplicat viatja dins del túnel sense canvis. També duplica la configuració que heu de mantenir coherent. El que no pot fer és que una adreça signifiqui dos amfitrions.
Canviar les adreces públiques dels parells VPN tampoc fa res. Aquestes adreces identifiquen els extrems del túnel, mentre que la col·lisió és al rang privat que es transporta a dins.
El tipus de connexió decideix si el NAT està disponible
Azure VPN Gateway sí que té una capacitat NAT, i està documentada per a connexions IPsec entre seus basades en rutes en SKU de passarel·la específics. La mateixa documentació exclou les connexions VNet-to-VNet i punt a lloc, així que la funció no és una casella que aparegui a totes les relacions de passarel·la.
| 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 |
La VNet-to-VNet nativa també requereix que els rangs de VNet i de xarxa local no se superposin des del principi, cosa coherent amb l'exclusió. L'emparellament de VNet no és una solució per a la superposició pel mateix motiu.
Hi ha una alternativa admesa que la gent confon amb el tipus natiu: modelar l'altra VNet com una xarxa local i connectar-la com a lloc a lloc. És un recurs diferent i un disseny diferent, així que tracteu una connexió reetiquetada com un canvi a validar, no com un simple canvi de nom.
Renumereu, o traduïu amb una cosa que posseeixi l'àlies
Si totes dues VNet són vostres, compareu una renumeració planificada amb el cost continu de la traducció. La renumeració toca la configuració d'aplicacions, els registres DNS, les regles de seguretat i cada connexió existent, però deixa una xarxa que després es llegeix amb normalitat. Feu-ho una subxarxa alhora, amb el canvi de DNS al final. Un rang mig renumerat és pitjor que qualsevol de les dues opcions, perquè llavors tots dos prefixos semblen autoritatius per a qui llegeixi la taula després.
On la renumeració no és pràctica, feu servir un disseny traduït amb un propietari real de l'àlies. Els qui criden des de la VNet A poden arribar a 10.40.1.10 de la VNet B com a 10.140.1.10, però aquest àlies necessita un dispositiu que tradueixi, una ruta cap a ell i un comportament equivalent per a la resposta. Una adreça afegida només al DNS no és una traducció.
Registreu tots dos rangs en totes dues direccions: què marca el qui crida, què veu la destinació com a origen i quin costat pot iniciar. Les regles NAT d'Azure inclouen la traducció inversa per a les seves assignacions SNAT, així que no escriviu a mà una regla DNAT equivalent, però aquesta comoditat s'atura als tipus de connexió que admet la funció.
Què no funcionarà
Una ruta definida per l'usuari o una mètrica de ruta no poden crear una distinció d'adreces que falta. Totes dues actuen sobre una destinació encara ambigua, i el paquet arriba al següent salt que la taula prefereixi.
Afegir el rang duplicat a una taula de rutes com a prefix més específic només mou l'ambigüitat un pas. També sol trencar l'altra direcció, on la resposta ara té dos orígens plausibles.
Accepteu el disseny amb trànsit en totes dues direccions
Proveu el disseny amb una operació permesa nova des de cada costat, no amb l'estat del túnel. Un túnel IPsec connectat diu que els parells acorden la criptografia; no diu res sobre si les destinacions s'han tornat distingibles.
Després executeu els camins denegats: una adreça que ha de romandre inabastable i un servei que la política ha de bloquejar. Si tots dos encara tenen èxit, la traducció és més àmplia del que pretenia el disseny.
Tanqueu amb els fets que expliquen la configuració més endavant: el rang original, el rang presentat, el dispositiu que tradueix i la direcció en què cada costat pot iniciar. Si falta algun d'aquests, el proper enginyer hereta una xarxa on dos amfitrions comparteixen nom i ningú recorda per què un d'ells respon.