Placez le VPN derrière un module Wi-Fi UART, pas à l’intérieur

Un microcontrôleur équipé d’un module Wi-Fi UART n’a pas besoin d’implémenter un VPN pour atteindre un service situé derrière. Le module exécute déjà une pile TCP/IP et expose des sockets par le port série, et une passerelle sur le même LAN peut acheminer ce trafic dans le tunnel. La conception ne fonctionne que si vous pouvez répondre à quatre questions dans l’ordre, alors traitez-la comme une liste de contrôle : adresse, socket, route, limite. Arrêtez-vous à la première porte qui échoue, car les suivantes ne peuvent pas la compenser.

Attribuez un rôle par couche

La liaison UART transporte les commandes AT et la charge utile entre le microcontrôleur et le module. Le module rejoint le réseau Wi-Fi et possède la connexion IP, y compris son adresse source. La passerelle possède le tunnel, les identifiants et la politique de transfert. C’est le fait de séparer ces rôles qui rend la conception débogable à chaque étape.

Cette séparation change aussi la façon d’écrire la politique de la passerelle. Une règle de source doit nommer l’adresse LAN du module, pas une adresse imaginaire pour le microcontrôleur derrière la liaison série. Le microcontrôleur n’a aucune identité IP propre dans cette conception, et faire semblant du contraire produit une règle qui ne correspond jamais.

Donnez au module une adresse stable par le mécanisme de réservation que le réseau prend en charge, ou placez les appareils sur leur propre segment et laissez la passerelle faire correspondre par interface. Une adresse de pool qui change après un redémarrage finira par casser une politique qui était correcte au moment où vous l’avez écrite.

La passerelle peut-elle nommer l’adresse du module ?

Avant qu’une socket ne s’ouvre, confirmez que le module est associé, qu’il a une adresse et que la passerelle le voit sur l’interface attendue. C’est la porte qui échoue le plus souvent en silence, car le module signalera volontiers une tentative de connexion qui n’a jamais quitté le LAN.

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

Le mode à connexion unique garde la séquence de commandes simple, et c’est le bon point de départ pour un capteur qui parle à un seul service. Le mode multi-connexions change la syntaxe de chaque commande ultérieure, alors décidez dans lequel vous êtes avant de copier un exemple d’une autre version de firmware.

Ouvrez la socket depuis le module

Une fois l’adresse et le mode fixés, le module peut ouvrir une connexion TCP vers le service privé. L’adresse ci-dessous est un exemple d’une plage de documentation ; remplacez-la par la vôtre et gardez la même forme.

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

Cette commande AT ouvre une socket TCP simple, et une socket n’est pas un tunnel : rien en elle ne crée un VPN et rien en elle ne chiffre la charge utile. Le mode TLS du firmware est une fonction distincte avec sa propre commande et sa propre gestion des certificats, et un module UART quelconque peut ne prendre en charge ni l’un ni l’autre. Consultez la référence des commandes AT TCP/IP de votre firmware plutôt que de supposer que la syntaxe ci-dessus s’y applique.

La longueur de la charge utile dans AT+CIPSEND doit correspondre à ce que vous envoyez réellement, sinon le module attendra des octets qui n’arrivent jamais et la connexion semblera bloquée. Cette panne ressemble à un problème réseau et vient presque toujours d’un décalage d’une unité dans la longueur.

Acheminez la connexion par la passerelle

La passerelle a besoin d’une route vers la destination privée, de l’autorisation de transférer du réseau des appareils vers le tunnel et d’un chemin de retour qui atteint le module. Si le côté distant ne route pas vers le sous-réseau des appareils, la conception a besoin d’une règle de traduction délibérée, et cette règle change l’identité source que voit le service.

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

Surveillez d’abord le chemin de retour. Un paquet transféré qui atteint le service et ne revient jamais produit un délai d’attente sur le module sans aucune erreur sur la passerelle, ce qui pousse les gens à scruter la liaison Wi-Fi pendant des heures. L’entrée conntrack vous dit si la passerelle a vu la réponse.

Décidez où le tunnel se termine réellement

Le tunnel commence à la passerelle. Il ne chiffre pas la liaison UART, et il ne transforme pas le segment LAN entre module et passerelle en partie du tunnel. Tout ce qui a besoin de protection sur ce segment a besoin de son propre mécanisme, et le TCP simple de cet exemple n’est pas TLS.

Décidez aussi de ce qui se passe quand le tunnel tombe. Si la livraison doit être uniquement via le VPN, la politique de transfert ne doit pas autoriser la même destination par une voie alternative, car une route de secours annule silencieusement l’exigence. Bornez le comportement de reconnexion pour qu’un module déconnecté n’inonde pas la liaison série ni le service distant de tentatives.

Notez les quatre réponses ensemble : l’adresse du module, la cible de la socket, la route de la passerelle et le point où commence le chiffrement. La prochaine personne qui déboguera cet appareil aura besoin des quatre, et aucune ne peut être déduite du seul firmware.