Aceeași subrețea la ambele capete: mapați LAN-ul îndepărtat pe un interval liber

Casa și biroul folosesc amândouă 192.168.1.0/24, așa că o cerere către 192.168.1.1 are două răspunsuri posibile și clientul alege unul fără să întrebe. Renumerotarea unei rețele de birou funcționale este rareori populară, iar adresele routerului sunt adesea încorporate în imprimante, camere și documentație. Maparea adreselor pe partea clientului poate prezenta în schimb rețeaua îndepărtată sub un interval liber, iar partea de gazdă poate rămâne aceeași, astfel încât 192.168.1.20 să apară ca 10.203.41.20. Problema este că doar unii clienți o implementează și că nu face nimic pentru calea de întoarcere.

Două vederi ale aceleiași gazde

Maparea păstrează partea de gazdă și schimbă doar partea de rețea. Aceeași mașină răspunde apoi la două adrese în funcție de unde vă aflați. Notarea ambelor coloane înainte de a configura ceva previne o citire greșită ulterioară a jurnalelor și a regulilor de firewall.

Dispozitivele locale din casă își păstrează propriile adrese 192.168.1.x, iar acesta este scopul exercițiului. Imprimanta din camera alăturată rămâne accesibilă în timp ce biroul apare sub un interval care nu se suprapune.

Ordinea argumentelor este întregul truc

Opțiunea ia o direcție, o rețea și o mască, și un alias: prima rețea este ceea ce vede clientul, aliasul este ceea ce vede serverul. Pentru resursele care stau în spatele gateway-ului îndepărtat, direcția este forma de destinație. Inversarea celor două rețele pentru că ultimul argument se numește alias este greșeala care produce un tunel care se conectează și nu mapează nimic.

push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"

Ruta este ceea ce trimite pachetele clientului pentru noul interval în tunel; traducerea rescrie destinația pe parcurs. Un răspuns de la 192.168.1.20 este rescris înapoi la 10.203.41.20 pentru ca socketul de pe client să rămână consecvent. O singură gazdă funcționează la fel cu o mască de lungime completă, atâta timp cât ruta și maparea descriu aceeași adresă.

Aceasta este o mapare de adrese, nu o mapare de porturi. Două servicii pe o singură gazdă nu pot fi separate cu ea, iar un protocol care încorporează adrese IP în payload-ul său va vedea totuși cele reale.

Maparea nu creează o cale de întoarcere

Traducerea are loc la client, așa că serverul trebuie în continuare să ruteze răspunsurile către tunel, iar firewall-ul său trebuie în continuare să le permită. Dacă gateway-ul îndepărtat nu știe cum să atingă subrețeaua tunelului, cererea ajunge și răspunsul iese pe ușa greșită; maparea doar face defecțiunea să pară o problemă a clientului.

Regulile de pe partea serverului ar trebui să descrie adresele care există pe server după traducere, nu intervalul vizibil clientului. Copierea aliasului într-o regulă de permisiune pierde o după-amiază, pentru că niciun pachet de pe acea parte nu îl poartă.

Alegeți un interval de alias care nu se suprapune cu nimic altceva ce clientul rutează: o altă VPN, o rețea de containere, un al doilea birou. O coliziune aici reintroduce ambiguitatea inițială sub alt număr și este mai greu de observat pentru că adresele par necunoscute.

Numele și payload-urile supraviețuiesc traducerii

Un nume de gazdă care se rezolvă la 192.168.1.20 real trimite browserul la dispozitivul local în loc de cel îndepărtat, indiferent ce spune tabelul de rutare. Răspunsul DNS privat trebuie să indice intervalul vizibil clientului, în timp ce certificatul TLS poartă în continuare numele pe care aplicația îl așteaptă. Testați cu numele, nu cu adresa, pentru că adresa poate funcționa în timp ce numele se rezolvă în liniște în direcția greșită. Când gateway-ul îndepărtat servește și acea zonă, înregistrările sale au nevoie și ele de intervalul vizibil clientului.

Redirecționările, URL-urile încorporate și aplicațiile care își dau propria adresă într-un payload se pot strica în moduri pe care nicio mapare de pachete nu le poate repara. Tratați-le ca pe o problemă de aplicație și dimensionați efortul în consecință înainte de a promite că renumerotarea nu este necesară.

Trei verificări înainte de a vă angaja

În primul rând, confirmați implementarea clientului. Community OpenVPN acceptă această opțiune; baza de cod OpenVPN 3 o enumeră printre funcțiile neacceptate, așa că un profil trimis unui client în stil Connect poate pur și simplu să o ignore. O directivă acceptată și niciodată aplicată este mai rea decât o eroare, pentru că tunelul pare sănătos.

În al doilea rând, verificați ruta și traducerea separat cu o fereastră de diagnosticare scurtă la verbositate ridicată, apoi testați serviciul real în loc de ping. În al treilea rând, confirmați că routerul local și resursa îndepărtată rămân distinse de client, deoarece acesta era obiectivul inițial.

Dacă clientul nu poate face traducerea, cereți ajutor din partea gateway-ului sau acceptați o renumerotare. Adăugarea mai multor rute pentru aceeași adresă nu este un proiect.