9.7. Reti private e NAT¶
IPv4 fu progettato con quattro miliardi di indirizzi, un numero che all’epoca sembrava sufficiente. Non lo è. Ogni casa, ufficio e fabbrica connessi a internet ha bisogno del proprio blocco di indirizzi per i dispositivi interni, e aggiungendo tutte le camere, i telefoni e gli elettrodomestici del mondo non restano certo quattro miliardi a disposizione.
La soluzione su cui internet si è assestato sono le reti private: la maggior parte dei dispositivi di una rete locale usa indirizzi che non sono univoci a livello globale ma solo all’interno di quella rete, e un unico dispositivo posto al confine traduce tra i due mondi. La camera, quasi sempre, si trova su una di queste reti private.
9.7.1. Gli intervalli di indirizzi privati¶
Tre intervalli IPv4 sono riservati come non instradabili sulla rete internet pubblica. Qualsiasi rete locale è libera di usare indirizzi all’interno di questi intervalli senza doversi coordinare con nessuno, perché nessun router al di fuori della rete locale tenterà mai di consegnare a essi:
10.0.0.0–10.255.255.255(16 milioni di indirizzi; comune nelle reti aziendali più grandi).172.16.0.0–172.31.255.255(circa un milione di indirizzi; meno comune nella pratica).192.168.0.0–192.168.255.255(65 mila indirizzi; il valore predefinito per quasi ogni router domestico).
In una tipica rete domestica la camera e il laptop che comunica con essa hanno entrambi indirizzi 192.168.x.x, perché è l’intervallo che il router domestico sceglie per la rete che ospita.
9.7.1.1. Come viene usata la netmask¶
La pagina Indirizzi IP ha introdotto la notazione /24. Il motivo per cui qui è importante è che la netmask è ciò che ogni dispositivo usa per decidere dove deve andare un pacchetto in seguito. Ogni volta che la camera invia un pacchetto, applica la propria netmask all’indirizzo di destinazione e osserva il risultato:
Se la destinazione condivide i bit di rete con l’indirizzo della camera stessa, la destinazione si trova sulla stessa rete locale. La camera le invia il pacchetto direttamente.
Se la destinazione non condivide i bit di rete, deve trovarsi su un’altra rete. La camera invia il pacchetto al proprio gateway predefinito (il router configurato automaticamente al momento del collegamento) e lascia che il gateway gestisca il resto.
Quell’unica verifica – «condividiamo i bit di rete?» – è a cosa serve la netmask. È anche il motivo per cui le reti domestiche usano per impostazione predefinita /24: un limite di 254 dispositivi è ampiamente sufficiente per un’abitazione e mantiene la rete semplice.
9.7.2. Network Address Translation¶
Una camera con indirizzo 192.168.1.50 non può semplicemente inviare un pacchetto a un server sulla rete internet pubblica – la rete internet pubblica non instrada verso 192.168.x.x. Il router domestico risolve questo problema con il Network Address Translation, o NAT, e lo fa in modo trasparente.
Il NAT riscrive l’indirizzo di origine dei pacchetti in uscita con l’indirizzo pubblico del router, e inverte la riscrittura sulle risposte in entrata, in modo che i dispositivi privati appaiano condividere un unico indirizzo pubblico.¶
Il router ha due indirizzi: uno privato sulla rete locale (comunemente 192.168.1.1) e uno pubblico assegnato dal provider internet. Quando la camera invia un pacchetto a un indirizzo pubblico, il router
registra l’indirizzo privato + porta della camera e lo associa a una porta in uscita temporanea propria;
riscrive l’indirizzo di origine sul pacchetto con il proprio indirizzo pubblico (e la porta di origine con la porta in uscita scelta);
invia il pacchetto riscritto sul lato pubblico.
Quando la risposta torna indietro indirizzata all’indirizzo pubblico + porta del router, il router cerca l’associazione, riscrive la destinazione riportandola all’indirizzo privato + porta della camera, e la consegna sul lato locale. La camera non sa mai che la riscrittura è avvenuta; il server non conosce mai l’origine originale.
Il NAT è ciò che rende pratiche le reti domestiche. Ha anche due conseguenze che vale la pena conoscere.
9.7.3. Cosa cambia il NAT¶
Il traffico in uscita è facile. Una camera su una rete privata può comunicare verso l’esterno liberamente. Ogni volta che apre una connessione TCP o invia un pacchetto UDP a un server remoto, il NAT imposta automaticamente l’associazione. La maggior parte delle applicazioni per camera funziona in questa direzione: catturare un’immagine, inviarla a un server da qualche parte, ricevere la risposta.
Il traffico in entrata è difficile. Un dispositivo sulla rete internet pubblica non può connettersi direttamente a una camera su una rete privata. Non esiste alcuna associazione che il router possa cercare quando un pacchetto non sollecitato arriva al suo indirizzo pubblico, quindi il pacchetto non ha dove andare. Il router lo scarta oppure lo consegna a un servizio in esecuzione sul router stesso.
Per il caso del traffico in entrata sono comuni tre soluzioni, in ordine grossomodo crescente di praticità:
Port forwarding. Configurare il router affinché diriga tutti i pacchetti in entrata su una determinata porta pubblica verso uno specifico dispositivo privato. Richiede l’accesso amministrativo al router; fragile quando l’indirizzo pubblico del router cambia.
VPN. Eseguire una rete privata virtuale che pone la camera sulla stessa rete logica di chi ha bisogno di raggiungerla. Pesante; al di fuori dell’ambito della maggior parte delle installazioni di camere.
Connessione avviata dall’esterno. La camera si connette verso l’esterno a un server noto da qualche parte sulla rete internet pubblica e mantiene quella connessione aperta; il server usa la connessione esistente per inviare messaggi di ritorno. È così che funzionano le notifiche push e la maggior parte dei protocolli per dispositivi connessi al cloud, ed è il pattern che la maggior parte delle applicazioni per camera finisce per utilizzare.
Il NAT è invisibile al codice Python sulla camera. Lo script comunica semplicemente con qualsiasi destinazione gli serva; il router gestisce la traduzione dietro le quinte. Ma la direzione della connessione è importante, ed è il NAT il motivo per cui «la camera si rivolge a un server cloud» è una forma molto più semplice di «un server cloud raggiunge la camera».