Mettete la VPN dietro un modulo Wi-Fi UART, non al suo interno

Un microcontrollore con un modulo Wi-Fi UART non deve implementare una VPN per raggiungere un servizio che sta dietro. Il modulo esegue già uno stack TCP/IP ed espone socket sulla porta seriale, e un gateway sulla stessa LAN può trasportare quel traffico nel tunnel. Il progetto funziona solo se riuscite a rispondere a quattro domande in ordine, quindi trattatelo come una lista di controllo: indirizzo, socket, rotta, confine. Fermatevi al primo cancello che fallisce, perché i successivi non possono compensarlo.

Assegnate un compito per livello

Il collegamento UART trasporta comandi AT e carico utile tra il microcontrollore e il modulo. Il modulo si unisce alla rete Wi-Fi e possiede la connessione IP, compreso il suo indirizzo di origine. Il gateway possiede il tunnel, le credenziali e la politica di inoltro. Tenere separati questi compiti è ciò che rende il progetto depurabile a ogni stadio.

La separazione cambia anche il modo in cui scrivete la politica del gateway. Una regola di origine deve nominare l’indirizzo LAN del modulo, non un indirizzo immaginario per il microcontrollore dietro il collegamento seriale. Il microcontrollore non ha un’identità IP propria in questo progetto, e fingere che ne abbia una produce una regola che non corrisponde mai.

Date al modulo un indirizzo stabile con qualunque meccanismo di prenotazione supporti la rete, oppure mettete i dispositivi su un segmento proprio e lasciate che il gateway faccia corrispondere per interfaccia. Un indirizzo del pool che cambia dopo un riavvio finirà per rompere una politica che era corretta quando l’avete scritta.

Il gateway può nominare l’indirizzo del modulo?

Prima che si apra qualsiasi socket, confermate che il modulo è associato, ha un indirizzo e che il gateway lo vede sull’interfaccia attesa. Questo è il cancello che fallisce più spesso in silenzio, perché il modulo segnalerà volentieri un tentativo di connessione che non ha mai lasciato la LAN.

AT+CWMODE=1
AT+CWJAP="lab-wifi","passphrase"
AT+CIPSTA?
AT+CIPMUX=0

La modalità a connessione singola mantiene semplice la sequenza di comandi, ed è il punto di partenza giusto per un sensore che parla con un solo servizio. La modalità a più connessioni cambia la sintassi di ogni comando successivo, quindi decidete in quale siete prima di copiare un esempio da un’altra versione di firmware.

Aprite il socket dal modulo

Con indirizzo e modalità definiti, il modulo può aprire una connessione TCP al servizio privato. L’indirizzo qui sotto è un esempio da un intervallo di documentazione; sostituitelo con il vostro e mantenete la stessa forma.

AT+CIPSTART="TCP","10.90.0.20",9000
AT+CIPSEND=18
{"t":21.4,"rh":48}

Quel comando AT apre un socket TCP semplice, e un socket non è un tunnel: nulla in esso crea una VPN e nulla in esso cifra il carico utile. La modalità TLS del firmware è una funzione separata con il proprio comando e la propria gestione dei certificati, e un modulo UART qualsiasi può non supportare né l’una né l’altra. Consultate la referenza dei comandi AT TCP/IP del vostro firmware invece di supporre che la sintassi qui sopra vi si applichi.

La lunghezza del carico utile in AT+CIPSEND deve corrispondere a ciò che inviate davvero, altrimenti il modulo attenderà byte che non arrivano mai e la connessione sembrerà bloccata. Quel guasto sembra un problema di rete ed è quasi sempre un errore di uno nella lunghezza.

Instradate la connessione attraverso il gateway

Il gateway ha bisogno di una rotta verso la destinazione privata, del permesso di inoltrare dalla rete dei dispositivi nel tunnel e di un percorso di ritorno che raggiunga il modulo. Se il lato remoto non instrada verso la sottorete dei dispositivi, il progetto ha bisogno di una regola di traduzione deliberata, e quella regola cambia l’identità di origine che vede il servizio.

ip route get 10.90.0.20
sudo tcpdump -ni wg0 'host 10.90.0.20 and port 9000'
sudo conntrack -L | grep 9000

Sorvegliate prima il percorso di ritorno. Un pacchetto inoltrato che raggiunge il servizio e non torna mai produce un timeout sul modulo senza alcun errore sul gateway, il che manda le persone a fissare il collegamento Wi-Fi per ore. La voce conntrack vi dice se il gateway ha visto la risposta.

Decidete dove finisce davvero il tunnel

Il tunnel inizia al gateway. Non cifra il collegamento UART, e non trasforma il segmento LAN tra modulo e gateway in parte del tunnel. Tutto ciò che necessita protezione su quel segmento necessita di un meccanismo proprio, e il TCP semplice di questo esempio non è TLS.

Decidete anche cosa succede quando il tunnel cade. Se la consegna deve avvenire solo tramite VPN, la politica di inoltro non deve consentire la stessa destinazione per una via alternativa, perché una rotta di riserva annulla in silenzio il requisito. Limitate il comportamento di riconnessione così che un modulo disconnesso non inondi il collegamento seriale o il servizio remoto di tentativi.

Annotate le quattro risposte insieme: l’indirizzo del modulo, il bersaglio del socket, la rotta del gateway e dove inizia la cifratura. La prossima persona che depurerà questo dispositivo avrà bisogno di tutte e quattro, e nessuna può essere dedotta dal solo firmware.