A VPN-t a UART Wi-Fi modul mögé tegye, ne bele

Az UART Wi-Fi modullal rendelkező mikrokontrollernek nem kell VPN-t megvalósítania ahhoz, hogy elérjen egy mögötte lévő szolgáltatást. A modul már futtat egy TCP/IP vermet, és soros porton keresztül csatlakozókat kínál, az ugyanabban a LAN-ban lévő átjáró pedig átviheti ezt a forgalmat az alagúton. A terv csak akkor működik, ha négy kérdésre sorrendben tud válaszolni, ezért kezelje ellenőrzőlistaként: cím, csatlakozó, útvonal, határ. Álljon meg az első kapunál, amelyik nem teljesül, mert a későbbiek nem tudják pótolni.

Minden rétegnek egy feladatot adjon

Az UART kapcsolat AT-parancsokat és hasznos terhelést visz át a mikrokontroller és a modul között. A modul csatlakozik a Wi-Fi hálózathoz, és birtokolja az IP-kapcsolatot, beleértve a saját forráscímét. Az átjáró birtokolja az alagutat, a hitelesítő adatokat és a továbbítási szabályzatot. Éppen e feladatok szétválasztása teszi a tervet minden szakaszban hibakereshetővé.

A szétválasztás megváltoztatja azt is, hogyan írja meg az átjáró szabályzatát. A forrásszabálynak a modul LAN-címét kell megneveznie, nem egy kitalált címet a soros kapcsolat mögötti mikrokontrollernek. A mikrokontrollernek ebben a tervben nincs saját IP-identitása, és ennek látszatát kelteni olyan szabályt hoz létre, amely soha nem illeszkedik.

Adjon a modulnak stabil címet a hálózat által támogatott bármely fenntartási mechanizmussal, vagy tegye az eszközöket saját szegmensükbe, és hagyja, hogy az átjáró interfész szerint párosítson. Az újraindítás után változó gyűjtőcímes cím végül megtöri azt a szabályzatot, amely a megírásakor helyes volt.

Meg tudja nevezni az átjáró a modul címét?

Mielőtt bármelyik csatlakozó megnyílik, erősítse meg, hogy a modul társítva van, van címe, és az átjáró a várt interfészen látja. Ez a kapu hibázik leggyakrabban csendben, mert a modul szívesen jelent egy olyan kapcsolódási kísérletet, amely soha nem hagyta el a LAN-t.

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

Az egykapcsolatos mód egyszerűen tartja a parancssorrendet, és ez a helyes kiindulópont egyetlen érzékelőhöz, amely egyetlen szolgáltatással beszél. A többkapcsolatos mód minden későbbi parancs szintaxisát megváltoztatja, ezért döntse el, melyikben van, mielőtt egy másik firmware-verzióból példát másol.

Nyissa meg a csatlakozót a modulból

Amikor a cím és a mód rögzített, a modul TCP-kapcsolatot nyithat a privát szolgáltatáshoz. Az alábbi cím egy dokumentációs tartományból származó példa; cserélje ki a sajátjára, és tartsa meg ugyanazt a formát.

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

Az az AT-parancs egyszerű TCP-csatlakozót nyit, a csatlakozó pedig nem alagút: semmi nem hoz létre benne VPN-t, és semmi nem titkosítja a hasznos terhelést. A firmware TLS-módja külön szolgáltatás, saját paranccsal és saját tanúsítványkezeléssel, és egy tetszőleges UART-modul egyiket sem feltétlenül támogatja. Nézze meg a firmware TCP/IP AT-parancsreferenciáját ahelyett, hogy feltételezné, a fenti szintaxis rá vonatkozik.

A AT+CIPSEND hasznos terhelésének hosszának egyeznie kell azzal, amit ténylegesen küld, különben a modul olyan bájtokra vár, amelyek soha nem érkeznek meg, és a kapcsolat lefagyottnak tűnik. Ez a hiba hálózati problémának látszik, és szinte mindig egy egységnyi eltérés a hosszban.

Irányítsa a kapcsolatot az átjárón keresztül

Az átjárónak útvonalra van szüksége a privát célhoz, engedélyre, hogy az eszközhálózatból az alagútba továbbítson, és egy visszaútra, amely eléri a modult. Ha a távoli oldal nem irányít vissza az eszköz alhálózatába, a tervnek szándékos fordítási szabályra van szüksége, és ez a szabály megváltoztatja azt a forrásidentitást, amelyet a szolgáltatás lát.

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

Először a visszautat figyelje. Egy továbbított csomag, amely eléri a szolgáltatást, és soha nem tér vissza, időtúllépést okoz a modulnál anélkül, hogy az átjárón bármilyen hiba lenne, és ez órákra a Wi-Fi kapcsolat bámulására készteti az embereket. A conntrack-bejegyzés megmondja, látta-e egyáltalán az átjáró a választ.

Döntse el, hol végződik valójában az alagút

Az alagút az átjárónál kezdődik. Nem titkosítja az UART kapcsolatot, és nem teszi az alagút részévé a modul és az átjáró közötti LAN-szegmenst. Mindennek, aminek ezen a szegmensen védelemre van szüksége, saját mechanizmusra van szüksége, és ebben a példában a sima TCP nem TLS.

Azt is döntse el, mi történik, amikor az alagút kiesik. Ha a kézbesítésnek csak VPN-en keresztül szabad történnie, a továbbítási szabályzat nem engedheti meg ugyanazt a célt alternatív útvonalon, mert a tartalék útvonal csendben érvényteleníti a követelményt. Korlátozza az újracsatlakozási viselkedést, hogy a lecsatlakozott modul ne árassza el a soros kapcsolatot vagy a távoli szolgáltatást próbálkozásokkal.

Jegyezze fel a négy választ együtt: a modul címét, a csatlakozó célját, az átjáró útvonalát és azt, hol kezdődik a titkosítás. A következő embernek, aki ezt az eszközt hibakeresi, mind a négyre szüksége lesz, és egyik sem vezethető le pusztán a firmware-ből.