Azure VPN NAT ne otklanja preklapanje adresa VNet mreža
Dvije VNet mreže s istim privatnim rasponom neće se spojiti samo zato što NAT postoji. Prvo provjerite vrstu veze, a zatim prenumerirajte ili posjedujte alias prijevoda.
Obje VNet mreže rabe 10.40.1.0/24, tuneli se podižu i ništa ne funkcionira. Dodavanje drugog VPN pristupnika to ne mijenja, a ni niža metrika rute, jer problem nije u odabiru putanje. Dva radna opterećenja koja odgovaraju na istu privatnu adresu ostavljaju svaki paket s nejasnim odredištem i neprovjerljivim povratnim putem. Prije planiranja bilo kakvog prijevoda, otkrijte koju ste vrstu veze doista izradili, jer taj jedini izbor određuje je li NAT značajka Azurea uopće dostupna.
Što vam simptom zapravo govori
Kada host u VNet A šalje na 10.40.1.10, tablica usmjeravanja može ga samo nekamo uputiti. Ako i VNet B sadrži 10.40.1.10, ta adresa nije odredište koje putanja može razlikovati; to je jedna adresa s dva vlasnika.
Drugi pristupnik koji ljudi obično uvode ne pomaže. Daje vam još jedan tunel, a ne još jednu adresu, a dvostruki raspon putuje unutar tunela nepromijenjen. Također udvostručuje konfiguraciju koju morate održavati usklađenom. Ono što ne može jest učiniti da jedna adresa znači dva hosta.
Promjena javnih adresa VPN partnera također ne pomaže. Te adrese označavaju krajnje točke tunela, dok je sukob u privatnom rasponu koji se prenosi unutar njega.
Vrsta veze određuje je li NAT dostupan
Azure VPN Gateway doista ima NAT mogućnost i ona je dokumentirana za IPsec veze između lokacija temeljene na rutama na određenim SKU-ovima pristupnika. Ista dokumentacija isključuje VNet-to-VNet i point-to-site veze, pa to nije potvrdni okvir koji se pojavljuje na svakom odnosu pristupnika.
| 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 |
Izvorni VNet-to-VNet također zahtijeva da se rasponi VNet mreže i lokalne mreže od početka ne preklapaju, što je u skladu s isključenjem. VNet peering nije rješenje za preklapanje iz istoga razloga.
Postoji podržana alternativa koju ljudi miješaju s izvornom vrstom: modelirajte drugu VNet mrežu kao lokalnu mrežu i povežite je kao vezu između lokacija. To je drugi resurs i drugi dizajn, pa preimenovanu vezu tretirajte kao promjenu koju treba validirati, a ne kao puko preimenovanje.
Prenumerirajte ili prevodite s nečim što posjeduje alias
Ako su obje VNet mreže vaše, usporedite planirano prenumeriranje s trajnim troškom prijevoda. Prenumeriranje dira konfiguraciju aplikacija, DNS zapise, sigurnosna pravila i svaku postojeću vezu, ali ostavlja mrežu koja se nakon toga čita normalno. Radite to jednu po jednu podmrežu, s promjenom DNS-a posljednjom. Napola prenumeriran raspon gori je od bilo koje opcije, jer tada oba prefiksa izgledaju mjerodavno onome tko sljedeći pročita tablicu.
Gdje prenumeriranje nije praktično, rabite prevedeni dizajn sa stvarnim vlasnikom aliasa. Pozivatelji u VNet A mogu dosegnuti 10.40.1.10 u VNet B kao 10.140.1.10, ali taj alias treba uređaj koji prevodi, rutu prema njemu i odgovarajuće ponašanje za odgovor. Adresa dodana samo u DNS nije prijevod.
Zabilježite oba raspona u obama smjerovima: što pozivatelj bira, što odredište vidi kao izvor i koja strana smije započeti. Azureova vlastita NAT pravila uključuju obrnuti prijevod za svoja SNAT preslikavanja, pa ne pišete odgovarajuće DNAT pravilo ručno, ali ta pogodnost prestaje kod vrsta veza koje značajka podržava.
Što neće funkcionirati
Korisnički definirana ruta ili metrika rute ne mogu stvoriti razliku adresa koja nedostaje. Obje djeluju na odredište koje je još nejasno, a paket stiže na sljedeći skok koji tablica preferira.
Dodavanje dvostrukog raspona u tablicu usmjeravanja kao specifičnijeg prefiksa pomiče nejasnoću samo jedan korak. Također obično kvari drugi smjer, gdje odgovor sada ima dva vjerojatna izvora.
Prihvatite dizajn s prometom u obama smjerovima
Dokažite dizajn svježom dopuštenom operacijom sa svake strane, ne statusom tunela. Povezani IPsec tunel kaže da su partneri suglasni o kriptografiji; ne kaže ništa o tome jesu li odredišta postala razlučiva.
Zatim pokrenite zabranjene putanje: adresu koja treba ostati nedostupna i uslugu koju politika treba blokirati. Ako oboje još uspijeva, prijevod je širi nego što je dizajn namjeravao.
Završite činjenicama koje kasnije objašnjavaju postavljanje: izvorni raspon, predstavljeni raspon, uređaj koji prevodi i smjer u kojem svaka strana smije započeti. Ako nešto od toga nedostaje, sljedeći inženjer nasljeđuje mrežu u kojoj dva hosta dijele ime i nitko se ne sjeća zašto jedan od njih odgovara.