de ce nat-ul e o idee proastă

sâmbătă, 25 feb. 2012, 11:53

În ciuda faptului că e în uz de circa douăzeci de ani și în pofida aceluia că cea mai mare parte a Internetului îl folosește în cadrul rețelelor sale (de obicei locale), NAT-ul e o idee proastă. Invers, deși folosirea NAT pe scară largă e o idee teribil de proastă, cea mai mare parte a Internetului îl implementează [i] sub semnul unei ignoranțe crase.

Network Address Translation e un mecanism prezent în majoritatea routerelor din comerț, mecanism ce prelucrează adresele sursă și/sau destinație într-o comunicație între două entități, spre a le „deghiza” [ii] în raport cu entitatea-partener, care poate fi sursa în cazul adresei destinație și vice-versa în celălalt caz. În practică este mai des întâlnit cazul translatării adresei sursă pentru date care pleacă dintr-o rețea formată din mai multe entități ce partajează o singură adresă publică, cazul invers fiind cunoscut sub numele de port forwarding.

Prima problemă a NAT-ului este una de ordin teoretic, ținând mai exact de proiectarea modelului OSI, pe care translatarea de adrese îl strică. Tanenbaum dixit, nivelul 3 descrie o rețea de calculatoare drept un sistem format din entități având adrese unice, ori masquerading-ul încalcă acest principiu prin introducerea ideii de rețea privată, violând astfel condiția de unicitate.

Acest lucru nu reprezintă o problemă în rețelele de telefonie, unde dacă eu am adresa 046-12345 iar Gicu are adresa 021-12345 – în acest caz 046 și respectiv 021 reprezentând prefixe de rețea sau oraș sau ce vreți voi -, atunci există un router care să identifice atât rețeaua 046 cât și rețeaua 021 și să livreze datele dintr-o parte în alta. Chestia asta devine imposibilă atunci când nu știu sau nu pot afla de existența 021 și de-a dreptul dezastruoasă atunci când există mai multe prefixe 021. Astfel putem verifica imediat că telefonia respectă de obicei [iii] ideea introdusă de nivelul rețea pe când rețelele IP cu NAT nu.

Problema de ordin practic constă în justificarea NAT-ului drept soluție la problema alocării de adrese IPv4, care nu prea mai sunt pentru că pe vremea proiectării protocolului nu credea nimeni că o să existe mai mult de o mie de mașini de calcul care vor comunica pe Internet [iv]. Așa-zisa soluție e, adică a fost cel mult paleativă, pentru că iată, cu tot cu NAT adresele IPv4 publice tot s-au cam terminat, bătând astfel încă un cui în cavoul chestiilor pe 32 de biți. Soluția cea adevărată este bineînțeles trecerea pe IPv6 și renunțarea definitivă la NAT. Bineînțeles că se vor trezi suficiente minți odihnite care să afirme că NAT-ul e necesar și pe IPv6 din motive de securitate. Lor le urăm numai bine, adică să învețe să-și configureze un firewall așa cum se face.

În fine, tot la capitolul „probleme de ordin practic” adăugăm ca exemple protocolul BitTorrent, al cărui mecanism de descoperire funcționează prost în contextul NAT-ului, jocurile online care încă mai folosesc servere private care necesită port forwarding [v], conexiunile FTP și altele.

Un exemplu de care m-am lovit recent este cel al pingback-ului peste WordPress, care poate fi stricat relativ ușor de un router având configurarea NAT-ului suficient de rudimentară. Deși protocolul peste care se realizează pingback-urile (sau mai degrabă implementarea lui în WordPress) vine cu o serie întreagă de surprize, sursa problemelor mele a fost de fapt NAT-ul, după cum vă voi descrie mai jos.

Dintr-un motiv străin mie, WordPress apelează wp-cron și/sau XML-RPC folosind URL-ul absolut al blog-ului (deși ar putea la fel de bine să apeleze localhost), adică în spate se face o cerere DNS pentru lucian.mogosanu.ro, care în prezent e mapat pe adresa 92.86.141.4. Problema cu adresa în cauză e că e interpretată incorect atunci când e accesată din rețeaua locală, unde se află server-ul web. Mai exact, routerele care nu au suport pentru NAT loopback nu știu să facă distincția între un acces la adresa lor publică și un acces la adresa lor din rețeaua locală, sau mai bine zis nu se trece prin NAT când e apelată adresa publică din cadrul rețelei locale. Astfel, router-ului Romtelecom pe care îl am acum îi este egal dacă îl accesez via 92.86.141.4 sau via 192.168.0.1, în ambele cazuri afișându-mi interfața sa web.

Soluția a fost evident adăugarea unei mapări suplimentare în fișierul /etc/hosts de pe server, constând în hostname-ul lucian.mogosanu.ro și adresa de loopback, adică 127.0.0.1. Problema a apărut fără să-mi dau seama în momentul în care sus-numita companie de telecomunicații mi-a oferit un router care nu se poate configura cu NAT loopback [vi], astfel că după ce am identificat problema și WordPress-ul a devenit iar capabil să trimită pingback-uri, acesta a comis un auto-DDoS, dat fiind faptul că s-a apucat să trimită toate pingback-urile care stăteau în coadă de circa un an.

Acestea fiind spuse, vă invit să vă bateți la cap providerii de Internet să vă dea drumul la IPv6, care deja nu mai e o tehnologie nouă și se cere adoptată în vreo minus câțiva ani de acum. Bineînțeles, același lucru îl voi face și eu, până la o soluție rămânând să mă amuz în continuare cu domenii care în rețeaua locală au o altă adresă decât în toate celelalte. Pentru că de-asta zic, NAT-ul e o idee îngrozitor de proastă.

  1. A se nota că folosesc termenul de NAT, deși mă refer în egală măsură și la omologul său PAT folosit peste TCP. []
  2. Termenul corect este „masquerading”. []
  3. Bănuiesc că mai există instituții care folosesc interioare – deci rețele private de telefonie – pentru a comunica. []
  4. Chestie care s-a dovedit a fi falsă, ca mai toate predicțiile „half-assed” făcute de-a lungul vremii în știință. []
  5. Problemă: ce fac în cazul în care am două servere în rețeaua privată și vreau să le translatez în cea publică? Răspuns: folosesc PAT pentru a aloca porturi suplimentare. Problemă: dar dacă toți clienții doresc din vreun motiv dubios să acceseze neapărat server-ul pe un port unic dat? Răspuns: o iau în mână. []
  6. Deși l-am hackuit destul de grav, ajungând în Linux-ul de pe dânsul și încercând să-i rescriu de la zero configurația iptables. []

Comentariile sunt dezactivate.