NAT na Azure VPN-u ne rešava preklapanje adresa VNet mreža
Dve VNet mreže sa istim privatnim opsegom neće se povezati samo zato što NAT postoji. Prvo proverite tip veze, a zatim prenumerišite ili posedujte alias prevoda.
Obe VNet mreže koriste 10.40.1.0/24, tuneli se podižu i ništa ne funkcioniše. Dodavanje drugog VPN gejtveja to ne menja, a ni niža metrika rute, jer problem nije u izboru putanje. Dva radna opterećenja koja odgovaraju na istu privatnu adresu ostavljaju svaki paket sa nejasnim odredištem i neproverljivim povratnim putem. Pre nego što isplanirate bilo kakav prevod, otkrijte koji ste tip veze zaista napravili, jer taj jedan izbor određuje da li je NAT funkcija Azurea uopšte dostupna.
Šta vam simptom zapravo govori
Kada host u VNet A šalje na 10.40.1.10, tabela ruta može ga samo negde usmeriti. Ako i VNet B sadrži 10.40.1.10, ta adresa nije odredište koje putanja može da razlikuje; to je jedna adresa sa dva vlasnika.
Drugi gejtvej koji ljudi obično postavljaju ne pomaže. Daje vam još jedan tunel, a ne još jednu adresu, a duplirani opseg putuje unutar tunela nepromenjen. Takođe udvostručuje konfiguraciju koju morate da održavate usklađenom. Ono što ne može jeste da učini da jedna adresa znači dva hosta.
Promena javnih adresa VPN partnera takođe ne čini ništa. Te adrese označavaju krajnje tačke tunela, dok je kolizija u privatnom opsegu koji se prenosi unutra.
Tip veze odlučuje da li je NAT dostupan
Azure VPN Gateway zaista ima NAT mogućnost, i ona je dokumentovana za IPsec veze između lokacija zasnovane na rutama na određenim gejtvej SKU-ovima. Ista dokumentacija isključuje VNet-to-VNet i point-to-site veze, pa to nije potvrdni okvir koji se pojavljuje na svakom gejtvej 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đe zahteva da se opsezi VNet mreže i lokalne mreže od početka ne preklapaju, što je u skladu sa isključenjem. VNet peering nije rešenje za preklapanje iz istog razloga.
Postoji podržana alternativa koju ljudi brkaju sa izvornim tipom: modelujte 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 promenu koju treba validirati, a ne kao puko preimenovanje.
Prenumerišite, ili prevodite sa nečim što poseduje alias
Ako su obe VNet mreže vaše, uporedite planirano prenumerisanje sa trajnim troškom prevoda. Prenumerisanje dira konfiguraciju aplikacija, DNS zapise, bezbednosna pravila i svaku postojeću vezu, ali ostavlja mrežu koja se nakon toga čita normalno. Radite to jednu po jednu podmrežu, sa promenom DNS-a na kraju. Napola prenumerisan opseg je gori od bilo koje opcije, jer tada oba prefiksa izgledaju merodavno onome ko sledeći pročita tabelu.
Gde prenumerisanje nije praktično, koristite prevedeni dizajn sa stvarnim vlasnikom aliasa. Pozivaoci u VNet A mogu da dosegnu 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 dodata samo u DNS nije prevod.
Zabeležite oba opsega u oba smera: šta pozivalac bira, šta odredište vidi kao izvor i koja strana sme da započne. Azureova sopstvena NAT pravila uključuju obrnuti prevod 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 funkcionisati
Korisnički definisana ruta ili metrika rute ne mogu da stvore razliku adresa koja nedostaje. Oba rade na odredištu koje je još nejasno, a paket stiže na sledeći skok koji tabela preferira.
Dodavanje dupliranog opsega u tabelu ruta kao specifičnijeg prefiksa pomera nejasnoću samo jedan korak. Takođe obično kvari drugi smer, gde odgovor sada ima dva verodostojna izvora.
Prihvatite dizajn sa saobraćajem u oba smera
Dokažite dizajn svežom dozvoljenom operacijom sa svake strane, ne statusom tunela. Povezan IPsec tunel kaže da su partneri saglasni o kriptografiji; ne kaže ništa o tome da li su odredišta postala razlučiva.
Zatim pokrenite zabranjene putanje: adresu koja treba da ostane nedostupna i uslugu koju politika treba da blokira. Ako oboje i dalje uspeva, prevod je širi nego što je dizajn nameravao.
Završite činjenicama koje kasnije objašnjavaju postavku: izvorni opseg, predstavljeni opseg, uređaj koji prevodi i smer u kojem svaka strana sme da započne. Ako nešto od toga nedostaje, sledeći inženjer nasleđuje mrežu u kojoj dva hosta dele ime i niko se ne seća zašto jedan od njih odgovara.