Când NAT din interiorul unui VPN site-la-site își merită locul

Ambele situri folosesc același interval privat, iar tunelul se ridică în timp ce nimic util nu-l traversează. Traducerea este răspunsul obișnuit și este un răspuns real: prezentarea unui alt interval părții îndepărtate poate rezolva o suprapunere sau o cale de întoarcere pe care cealaltă rețea nu o poate ruta. Partea omisă este că traducerea schimbă adresele pe care le vede fiecare decizie ulterioară. Tratați-o ca o decizie de proiectare documentată, cu o mapare scrisă, nu ca o regulă adăugată până când un ping reușește.

Decideți care adresă este rescrisă

Traducerea sursei schimbă ceea ce serviciul îndepărtat și jurnalele sale văd ca client, astfel încât un host de sucursală devine o adresă de gateway la sosire. Traducerea destinației sau a prefixului prezintă în schimb o adresă alternativă pentru o resursă îndepărtată. Unele implementări au nevoie de traducere coordonată pe ambele părți pentru a separa două rețele altfel identice, iar în combinație începe cea mai mare parte a confuziei.

Notați sursa înainte de traducere, destinația așa cum o numește aplicația și perechea de adrese cu care se potrivește fiecare gateway. Trei coloane sunt suficiente, iar a treia coloană este cea pe care oamenii o omit.

Ordinea selectorilor contează și ea. Selectarea și traducerea politicii IPsec au loc în etape definite, așa că un selector scris pentru adrese dinaintea traducerii poate să nu se potrivească niciodată cu pachetul în etapa pe care ați presupus-o. Verificați politica instalată, nu politica pe care intenționați să o instalați, pentru că cele două diverg exact atunci când o regulă este acceptată de o componentă și ignorată de alta:

ip xfrm policy show
ip xfrm state show
nft list ruleset | grep -A4 nat

Urmați payload-ul și calea de întoarcere

Un server care înregistrează sursa tradusă în locul hostului individual de sucursală va rupe orice regulă sau raport legat de adresa originală. Înainte de a schimba maparea, aflați dacă ceva în aval ia o decizie pe baza acelui câmp: liste de acces, rapoarte de audit, limite de viteză, verificări de licență. Fiecare dintre acestea este un loc unde traducerea apare mai târziu ca o defecțiune neexplicată.

Protocoalele care transportă adrese în payload-ul lor necesită planificare separată, deoarece rescrierea antetului extern nu atinge referința internă. FTP activ, SIP și unele produse de acces la distanță sunt cazurile clasice, iar un design care le ignoră va funcționa pentru traficul web și va eșua pentru aplicația care conta.

Traficul de întoarcere depinde de mapări cu stare. Failover-ul gateway-ului poate pierde acea stare, rutarea asimetrică o poate ocoli, iar o repornire o poate șterge în timp ce sesiunile rămân deschise pe partea îndepărtată. De aceea o cerere care ajunge la destinație și o sesiune care se finalizează sunt două rezultate de acceptare diferite.

Cântăriți-o față de renumerotarea unui sit

Renumerotarea unui sit conflictual elimină complet maparea și lasă un plan de adrese care poate fi citit fără tabele de traducere. Este costisitoare operațional: înregistrările DNS, alocările statice, regulile de firewall și fiecare adresă documentată trebuie schimbate împreună. Costul apare o dată, într-o fereastră planificată, cu o stare finală clară. Ceea ce cumpărați este capacitatea de a citi o captură de pachete ani mai târziu fără un tabel de căutare.

Traducerea evită majoritatea modificărilor locale și creează o mapare care trebuie întreținută în DNS, documentație și depanare pentru totdeauna. Costul apare continuu, sub forma fiecărui viitor inginer care trebuie să învețe că un prefix înseamnă altceva în interiorul tunelului.

Pentru o conexiune temporară sau o rețea de partener pe care nu o controlați, costul continuu merită de obicei. Pentru două situri pe care le dețineți și le veți deține ani de zile, renumerotarea este adesea decizia mai ieftină atunci când migrarea este calculată cinstit.

Dovediți ambele direcții cu o sesiune reală

Testați o sesiune de aplicație, nu o singură sondă. O cerere de ecou reușită dovedește că o direcție a unui protocol funcționează și este perfect compatibilă cu o cale de întoarcere care eșuează pentru orice are stare. Folosiți serviciul care a motivat designul și citiți jurnalul acestuia la capătul îndepărtat pentru a vedea ce adresă sursă a înregistrat.

tcpdump -ni any host 10.40.9.20 and port 443
conntrack -L | grep 10.40.9.20
ip route get 10.40.9.20

Apoi confirmați că numai serviciile dorite sunt accesibile prin mapare. Traducerea schimbă adresarea și nu face nimic pentru autorizare, așa că politica firewall-ului decide în continuare ce este permis. Un design care se bazează pe un prefix tradus obscur ca control de acces nu are niciun control de acces.

Înregistrați maparea, sesiunea testată și adresele observate de fiecare parte. Următoarea persoană care va depana acest tunel are nevoie de cele trei fapte mai mult decât de fișierul de configurare.