9.7. Rețele private și NAT

IPv4 a fost proiectat cu patru miliarde de adrese, ceea ce părea suficient la momentul respectiv. Nu este. Fiecare locuință, birou și fabrică conectată la internet are nevoie de propriul bloc de adrese pentru dispozitivele sale interne, iar dacă adăugăm toate camerele, telefoanele și aparatele din lume, nu mai rămân patru miliarde la dispoziție.

Soluția de compromis pe care a adoptat-o internetul este rețelele private: majoritatea dispozitivelor dintr-o rețea locală folosesc adrese care nu sunt unice la nivel global, ci doar în interiorul acelei rețele, iar un singur dispozitiv aflat la margine face traducerea între cele două lumi. Camera se află, aproape întotdeauna, pe una dintre aceste rețele private.

9.7.1. Intervalele de adrese private

Trei intervale IPv4 sunt rezervate ca nerutabile pe internetul public. Orice rețea locală poate folosi liber adrese din interiorul acestor intervale fără a se coordona cu nimeni, deoarece niciun ruter din afara rețelei locale nu va încerca vreodată să livreze pachete către ele:

• 10.0.0.0 – 10.255.255.255 (16 milioane de adrese; frecvent în rețelele corporative mari).

• 172.16.0.0 – 172.31.255.255 (aproximativ un milion de adrese; mai puțin întâlnit în practică).

• 192.168.0.0 – 192.168.255.255 (65 de mii de adrese; valoarea implicită pentru aproape orice ruter de uz casnic).

Într-o rețea casnică tipică, atât camera, cât și laptopul care comunică cu ea se află pe adrese 192.168.x.x, deoarece acesta este intervalul pe care ruterul casnic îl alege pentru rețeaua pe care o găzduiește.

9.7.1.1. Cum este folosită masca de rețea

Pagina Adrese IP a introdus notația /24. Motivul pentru care contează aici este că masca de rețea este ceea ce folosește fiecare dispozitiv pentru a decide încotro trebuie să meargă mai departe un pachet. De fiecare dată când camera trimite un pachet, aplică propria mască de rețea adresei de destinație și analizează rezultatul:

• Dacă destinația împarte biții de rețea cu adresa proprie a camerei, destinația se află pe aceeași rețea locală. Camera îi trimite pachetul direct.

• Dacă destinația nu împarte biții de rețea, atunci trebuie să se afle pe o altă rețea. Camera trimite pachetul către gateway-ul implicit (ruterul configurat automat la stabilirea legăturii) și lasă gateway-ul să se ocupe de restul.

Acel singur test – „împărțim biți de rețea?” – este scopul măștii de rețea. Este și motivul pentru care rețelele casnice folosesc implicit /24: o limită de 254 de dispozitive se potrivește confortabil unei gospodării și păstrează rețeaua simplă.

9.7.2. Network Address Translation

O cameră aflată pe 192.168.1.50 nu poate pur și simplu să trimită un pachet către un server de pe internetul public – internetul public nu rutează către 192.168.x.x. Ruterul casnic rezolvă acest lucru cu Network Address Translation, sau NAT, și o face în mod transparent.

NAT rescrie adresa sursă a pachetelor de ieșire cu adresa publică a ruterului și inversează rescrierea la răspunsurile de intrare, astfel încât dispozitivele private par să folosească în comun o singură adresă publică.

Ruterul are două adrese: una privată în rețeaua locală (de obicei 192.168.1.1) și una publică, atribuită de furnizorul de internet. Când camera trimite un pachet către o adresă publică, ruterul

1. înregistrează adresa privată + portul camerei și le asociază cu un port temporar de ieșire propriu;

2. rescrie adresa sursă din pachet cu propria adresă publică (iar portul sursă cu portul de ieșire ales);

3. trimite pachetul rescris pe partea publică.

Când răspunsul revine adresat către adresa publică + portul ruterului, ruterul caută asocierea, rescrie destinația înapoi la adresa privată + portul camerei și îl livrează pe partea locală. Camera nu află niciodată că rescrierea a avut loc; serverul nu cunoaște niciodată sursa originală.

NAT este ceea ce face rețelele casnice practice. Are însă și două consecințe pe care merită să le cunoaștem.

9.7.3. Ce schimbă NAT

Ieșirea este simplă. O cameră dintr-o rețea privată poate comunica spre exterior fără restricții. De fiecare dată când deschide o conexiune TCP sau trimite un pachet UDP către un server la distanță, NAT configurează automat asocierea. Majoritatea aplicațiilor pentru cameră funcționează în această direcție: captează o imagine, o trimit către un server undeva, primesc răspunsul.

Intrarea este dificilă. Un dispozitiv de pe internetul public nu se poate conecta direct la o cameră dintr-o rețea privată. Nu există nicio asociere pe care ruterul să o poată căuta atunci când la adresa sa publică sosește un pachet nesolicitat, așa că pachetul nu are unde să meargă. Ruterul fie îl renunță, fie îl predă unui serviciu care rulează chiar pe ruter.

Trei soluții de compromis pentru cazul de intrare sunt frecvente, aproximativ în ordine crescătoare a practicabilității:

• Redirecționarea de porturi (port forwarding). Configurați ruterul să direcționeze toate pachetele de intrare de pe un port public ales către un dispozitiv privat specific. Necesită acces de administrator la ruter; este fragilă atunci când adresa publică a ruterului se schimbă.

• VPN. Rulați o rețea privată virtuală care plasează camera pe aceeași rețea logică precum cel care trebuie să o acceseze. Greoaie; în afara scopului majorității implementărilor cu cameră.

• Conexiune inițiată din interior. Camera se conectează spre exterior la un server cunoscut undeva pe internetul public și menține acea conexiune deschisă; serverul folosește conexiunea existentă pentru a trimite mesaje înapoi. Așa funcționează notificările push și majoritatea protocoalelor pentru dispozitive conectate la cloud, și este modelul pe care îl folosesc în cele din urmă majoritatea aplicațiilor pentru cameră.

NAT este invizibil pentru codul Python de pe cameră. Scriptul pur și simplu comunică cu destinația de care are nevoie; ruterul se ocupă de traducere în culise. Dar direcția conexiunii contează cu adevărat, iar NAT este motivul pentru care „camera ajunge la un server din cloud” este o configurație mult mai simplă decât „un server din cloud ajunge la cameră”.