NAT na Azure VPN-u ne rješava preklapanje adresa VNet mreža
Dvije VNet mreže s istim privatnim rasponom neće se povezati samo zato što NAT postoji. Prvo provjerite tip veze, a zatim prenumerišite ili posjedujte alias za prevođenje.
Obje VNet mreže koriste 10.40.1.0/24, tuneli se podižu i ništa ne radi. Dodavanje drugog VPN gatewaya to ne mijenja, a ni niža metrika rute, jer problem nije u odabiru puta. Dva radna opterećenja koja odgovaraju na istu privatnu adresu ostavljaju svaki paket s dvosmislenim odredištem i neprovjerljivim povratnim putem. Prije nego što isplanirate bilo kakvo prevođenje, otkrijte koji ste tip veze zaista kreirali, jer taj jedan izbor odlučuje je li NAT funkcija Azurea uopće dostupna.
Šta vam simptom zapravo govori
Kada host u VNet A šalje na 10.40.1.10, tabela ruta može ga samo usmjeriti negdje. Ako i VNet B sadrži 10.40.1.10, ta adresa nije odredište koje put može razlikovati; to je jedna adresa s dva vlasnika.
Drugi gateway koji ljudi obično postavljaju ne pomaže. On vam daje još jedan tunel, a ne još jednu adresu, a duplicirani 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 čini ništa. Te adrese identificiraju krajnje točke tunela, dok je kolizija u privatnom rasponu koji se prenosi unutar njega.
Tip veze odlučuje je li NAT dostupan
Azure VPN Gateway zaista ima NAT mogućnost, i ona je dokumentirana za IPsec veze između lokacija zasnovane na rutama na određenim gateway SKU-ovima. Ista dokumentacija isključuje VNet-to-VNet i point-to-site veze, pa to nije potvrdni okvir koji se pojavljuje na svakom gateway odnosu.
| 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 ne preklapaju od početka, što je u skladu s isključenjem. VNet peering nije rješenje za preklapanje iz istog razloga.
Postoji podržana alternativa koju ljudi brkaju s izvornim tipom: 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 preimenovanje.
Prenumerišite, ili prevodite s nečim što posjeduje alias
Ako su obje VNet mreže vaše, uporedite planirano prenumerisanje s trajnim troškom prevođenja. Prenumerisanje 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 na kraju. Napola prenumerisan raspon gori je od bilo koje opcije, jer tada oba prefiksa izgledaju mjerodavno onome ko sljedeći pročita tabelu.
Gdje prenumerisanje nije praktično, koristite prevedeni dizajn sa stvarnim vlasnikom aliasa. Pozivaoci u VNet A možda dosežu 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 prevođenje.
Zabilježite oba raspona u oba smjera: šta pozivalac bira, šta odredište vidi kao izvor i koja strana smije inicirati. Azureova vlastita NAT pravila uključuju obrnuto prevođenje za svoja SNAT mapiranja, pa ne pišete odgovarajuće DNAT pravilo ručno, ali ta pogodnost prestaje kod tipova veza koje funkcija podržava.
Šta neće raditi
Korisnički definirana ruta ili metrika rute ne mogu stvoriti razliku adresa koja nedostaje. Oba rade na odredištu koje je još dvosmisleno, a paket stiže na sljedeći hop koji tabela preferira.
Dodavanje dupliciranog raspona u tabelu ruta kao specifičnijeg prefiksa pomjera dvosmislenost samo jedan korak. Također obično kvari drugi smjer, gdje odgovor sada ima dva vjerodostojna izvora.
Prihvatite dizajn s prometom u oba smjera
Dokažite dizajn svježom dozvoljenom operacijom sa svake strane, ne statusom tunela. Povezani IPsec tunel kaže da su partneri složni 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 i dalje uspije, prevođenje je šire nego što je dizajn namjeravao.
Završite činjenicama koje kasnije objašnjavaju postavku: izvorni raspon, predstavljeni raspon, uređaj koji prevodi i smjer u kojem svaka strana smije inicirati. 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.