NAT-ul din Azure VPN nu rezolvă adresele VNet suprapuse
Două VNet cu același interval privat nu se conectează doar pentru că există NAT. Verificați mai întâi tipul conexiunii, apoi renumerotați sau dețineți un alias de traducere.
Ambele VNet folosesc 10.40.1.0/24, tunelurile urcă și nimic nu funcționează. Adăugarea unui al doilea gateway VPN nu schimbă asta, nici o metrică de rută mai mică, pentru că problema nu este selecția căii. Două sarcini de lucru care răspund la aceeași adresă privată lasă fiecare pachet cu o destinație ambiguă și o cale de întoarcere neverificabilă. Înainte de a planifica orice traducere, aflați ce tip de conexiune ați creat de fapt, pentru că acea singură alegere decide dacă funcția NAT din Azure este disponibilă sau nu.
Ce vă spune de fapt simptomul
Când un gazdă din VNet A trimite la 10.40.1.10, tabela de rutare o poate îndrepta doar undeva. Dacă VNet B conține și 10.40.1.10, acea adresă nu este o destinație pe care calea o poate distinge; este o adresă cu doi proprietari.
Al doilea gateway pe care oamenii îl implementează de obicei nu ajută. Vă oferă un alt tunel, nu o altă adresă, iar intervalul duplicat călătorește neschimbat în interiorul tunelului. De asemenea, dublează configurația pe care trebuie să o mențineți consecventă. Ce nu poate face este să facă o adresă să însemne doi gazde.
Schimbarea adreselor publice ale partenerilor VPN nu face nici ea nimic. Acele adrese identifică extremitățile tunelului, în timp ce coliziunea este în intervalul privat transportat în interior.
Tipul conexiunii decide dacă NAT este disponibil
Azure VPN Gateway are într-adevăr o capacitate NAT, iar aceasta este documentată pentru conexiunile IPsec între locații bazate pe rute pe anumite SKU-uri de gateway. Aceeași documentație exclude conexiunile VNet-to-VNet și point-to-site, așa că funcția nu este o casetă de selectare care apare la fiecare relație de gateway.
| 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 |
VNet-to-VNet nativ cere, de asemenea, ca intervalele VNet și ale rețelei locale să nu se suprapună de la început, ceea ce este în concordanță cu excluderea. Nici împerecherea VNet nu este o soluție pentru suprapunere, din același motiv.
Există o alternativă acceptată pe care oamenii o confundă cu tipul nativ: modelați cealaltă VNet ca rețea locală și conectați-o ca legătură de la site la site. Acesta este altă resursă și alt proiect, așa că tratați o conexiune redenumită ca o modificare de validat, nu ca o simplă schimbare de nume.
Renumerotați sau traduceți cu ceva care deține aliasul
Dacă ambele VNet sunt ale dumneavoastră, comparați renumerotarea planificată cu costul continuu al traducerii. Renumerotarea atinge configurația aplicațiilor, înregistrările DNS, regulile de securitate și fiecare conexiune existentă, dar lasă o rețea care se citește normal după aceea. Faceți-o câte o subrețea pe rând, cu modificarea DNS ultima. Un interval pe jumătate renumerotat este mai rău decât ambele opțiuni, pentru că atunci ambele prefixe par autoritare pentru cine citește tabelul următor.
Acolo unde renumerotarea nu este practică, folosiți un proiect tradus cu un proprietar real pentru alias. Cei care apelează din VNet A pot ajunge la 10.40.1.10 din VNet B ca 10.140.1.10, dar acel alias are nevoie de un dispozitiv care traduce, de o rută către el și de un comportament corespunzător pentru răspuns. O adresă adăugată doar în DNS nu este o traducere.
Înregistrați ambele intervale în ambele direcții: ce formează apelantul, ce vede destinația ca sursă și care parte poate iniția. Regulile NAT ale Azure includ traducerea inversă pentru mapările lor SNAT, așa că nu scrieți de mână o regulă DNAT corespunzătoare, dar acest confort se oprește la tipurile de conexiune pe care funcția le acceptă.
Ce nu va funcționa
O rută definită de utilizator sau o metrică de rută nu pot crea o distincție de adrese lipsă. Ambele acționează asupra unei destinații încă ambigue, iar pachetul ajunge la următorul salt pe care tabela îl preferă.
Adăugarea intervalului duplicat într-o tabelă de rutare ca prefix mai specific mută ambiguitatea doar un pas. De asemenea, tinde să strice direcția opusă, unde răspunsul are acum două surse plauzibile.
Acceptați proiectul cu trafic în ambele direcții
Demonstrați proiectul printr-o operațiune permisă nouă din fiecare parte, nu prin starea tunelului. Un tunel IPsec conectat spune că partenerii sunt de acord asupra criptografiei; nu spune nimic despre dacă destinațiile au devenit distingibile.
Apoi rulați căile refuzate: o adresă care trebuie să rămână inaccesibilă și un serviciu pe care politica trebuie să îl blocheze. Dacă ambele reușesc în continuare, traducerea este mai largă decât a intenționat proiectul.
Încheiați cu faptele care explică configurația mai târziu: intervalul original, intervalul prezentat, dispozitivul care traduce și direcția în care fiecare parte poate iniția. Dacă lipsește vreuna, următorul inginer moștenește o rețea în care doi gazde împart un nume și nimeni nu își amintește de ce unul dintre ei răspunde.