Setzen Sie das VPN hinter ein UART-Wi-Fi-Modul, nicht hinein
Ein UART-Wi-Fi-Modul braucht einen TCP-Socket, das Gateway besitzt den Tunnel. Benennen Sie seine Adresse, halten Sie den Rückweg offen und wissen Sie, wo die Verschlüsselung beginnt.
Ein Mikrocontroller mit UART-Wi-Fi-Modul muss kein VPN implementieren, um einen Dienst dahinter zu erreichen. Das Modul betreibt bereits einen TCP/IP-Stack und stellt Sockets über die serielle Schnittstelle bereit, und ein Gateway im selben LAN kann diesen Verkehr durch den Tunnel führen. Das Design funktioniert nur, wenn Sie vier Fragen der Reihe nach beantworten können, also behandeln Sie es als Checkliste: Adresse, Socket, Route, Grenze. Bleiben Sie am ersten Tor stehen, das scheitert, denn die späteren können es nicht ausgleichen.
Geben Sie jeder Schicht eine Aufgabe
Die UART-Verbindung überträgt AT-Befehle und Nutzlast zwischen dem Mikrocontroller und dem Modul. Das Modul tritt dem Wi-Fi-Netz bei und besitzt die IP-Verbindung einschließlich ihrer Quelladresse. Das Gateway besitzt den Tunnel, die Zugangsdaten und die Weiterleitungsrichtlinie. Diese Aufgaben getrennt zu halten macht das Design in jeder Phase debugbar.
Die Trennung ändert auch, wie Sie die Gateway-Richtlinie schreiben. Eine Quellregel sollte die LAN-Adresse des Moduls benennen, nicht eine erfundene Adresse für den Mikrocontroller hinter der seriellen Verbindung. Der Mikrocontroller hat in diesem Design keine eigene IP-Identität, und so zu tun, als hätte er eine, erzeugt eine Regel, die nie passt.
Geben Sie dem Modul eine stabile Adresse über den Reservierungsmechanismus, den das Netzwerk unterstützt, oder legen Sie die Geräte in ein eigenes Segment und lassen Sie das Gateway nach Schnittstelle zuordnen. Eine Pooladresse, die sich nach einem Neustart ändert, wird irgendwann eine Richtlinie brechen, die korrekt war, als Sie sie schrieben.
Kann das Gateway die Adresse des Moduls benennen?
Bevor irgendein Socket geöffnet wird, bestätigen Sie, dass das Modul assoziiert ist, eine Adresse hat und dass das Gateway es auf der erwarteten Schnittstelle sieht. Dies ist das Tor, das am häufigsten still scheitert, denn das Modul meldet bereitwillig einen Verbindungsversuch, der das LAN nie verlassen hat.
AT+CWMODE=1 AT+CWJAP="lab-wifi","passphrase" AT+CIPSTA? AT+CIPMUX=0
Der Einzelverbindungsmodus hält die Befehlsfolge einfach und ist der richtige Ausgangspunkt für einen Sensor, der mit einem Dienst spricht. Der Mehrverbindungsmodus ändert die Syntax jedes späteren Befehls, also entscheiden Sie, in welchem Sie sind, bevor Sie ein Beispiel aus einer anderen Firmware-Version kopieren.
Öffnen Sie den Socket vom Modul aus
Mit geklärter Adresse und geklärtem Modus kann das Modul eine TCP-Verbindung zum privaten Dienst öffnen. Die Adresse unten ist ein Beispiel aus einem Dokumentationsbereich; ersetzen Sie sie durch Ihre eigene und behalten Sie dieselbe Form.
AT+CIPSTART="TCP","10.90.0.20",9000
AT+CIPSEND=18
{"t":21.4,"rh":48}
Dieser AT-Befehl öffnet einen einfachen TCP-Socket, und ein Socket ist kein Tunnel: nichts darin erzeugt ein VPN und nichts darin verschlüsselt die Nutzlast. Der TLS-Modus der Firmware ist eine separate Funktion mit eigenem Befehl und eigener Zertifikatsbehandlung, und ein beliebiges UART-Modul unterstützt möglicherweise keines von beiden. Prüfen Sie die TCP/IP-AT-Befehlsreferenz für Ihre Firmware, statt anzunehmen, dass die obige Syntax dafür gilt.
Die Nutzlastlänge in AT+CIPSEND muss zu dem passen, was Sie tatsächlich senden, sonst wartet das Modul auf Bytes, die nie ankommen, und die Verbindung scheint zu hängen. Dieser Fehler sieht wie ein Netzwerkproblem aus und ist fast immer ein Off-by-one in der Länge.
Leiten Sie die Verbindung über das Gateway
Das Gateway braucht eine Route zum privaten Ziel, die Erlaubnis, vom Gerätenetz in den Tunnel weiterzuleiten, und einen Rückweg, der das Modul erreicht. Wenn die Gegenseite nicht ins Gerätesubnetz zurückroutet, braucht das Design eine bewusste Übersetzungsregel, und diese Regel ändert die Quellidentität, die der Dienst sieht.
ip route get 10.90.0.20 sudo tcpdump -ni wg0 'host 10.90.0.20 and port 9000' sudo conntrack -L | grep 9000
Achten Sie zuerst auf den Rückweg. Ein weitergeleitetes Paket, das den Dienst erreicht und nie zurückkommt, erzeugt am Modul eine Zeitüberschreitung ohne jeden Fehler am Gateway, was Leute stundenlang auf die Wi-Fi-Verbindung schauen lässt. Der conntrack-Eintrag sagt Ihnen, ob das Gateway die Antwort überhaupt gesehen hat.
Entscheiden Sie, wo der Tunnel tatsächlich endet
Der Tunnel beginnt am Gateway. Er verschlüsselt die UART-Verbindung nicht und macht das LAN-Segment zwischen Modul und Gateway nicht zu einem Teil des Tunnels. Alles, was in diesem Segment Schutz braucht, braucht einen eigenen Mechanismus, und einfaches TCP ist in diesem Beispiel kein TLS.
Entscheiden Sie auch, was passiert, wenn der Tunnel wegfällt. Wenn die Zustellung nur über VPN erfolgen darf, darf die Weiterleitungsrichtlinie dasselbe Ziel nicht über einen alternativen Pfad erlauben, denn eine Ausweichroute untergräbt die Anforderung still. Begrenzen Sie das Wiederverbindungsverhalten, damit ein getrenntes Modul die serielle Verbindung oder den entfernten Dienst nicht mit Wiederholungen überflutet.
Notieren Sie die vier Antworten zusammen: die Adresse des Moduls, das Socket-Ziel, die Gateway-Route und wo die Verschlüsselung beginnt. Die nächste Person, die dieses Gerät debuggt, braucht alle vier, und keine davon lässt sich allein aus der Firmware ableiten.