Տեղադրեք VPN-ը UART Wi-Fi մոդուլի հետևում, ոչ թե դրա ներսում
UART Wi-Fi մոդուլին TCP սոկետ է պետք, իսկ թունելը պատկանում է դարպասին։ Անվանեք դրա հասցեն, բաց պահեք վերադարձի ուղին և իմացեք, թե որտեղից է սկսվում գաղտնագրումը։
UART Wi-Fi մոդուլ ունեցող միկրոկարգավորիչը կարիք չունի VPN ներդնելու՝ դրա հետևում գտնվող ծառայությանը հասնելու համար։ Մոդուլն արդեն աշխատացնում է TCP/IP կույտ և սոկետներ է տրամադրում սերիական պորտով, իսկ նույն LAN-ի դարպասը կարող է այդ երթևեկն անցկացնել թունելով։ Նախագիծն աշխատում է միայն այն դեպքում, երբ կարող եք հերթով պատասխանել չորս հարցի, ուստի վերաբերվեք դրան որպես ստուգաթերթ՝ հասցե, սոկետ, երթուղի, սահման։ Կանգ առեք առաջին դարպասի մոտ, որը ձախողվում է, քանի որ հաջորդները չեն կարող փոխհատուցել այն։
Յուրաքանչյուր շերտին մեկ աշխատանք տվեք
UART կապը AT հրամաններ և բեռնվածք է տեղափոխում միկրոկարգավորիչի ու մոդուլի միջև։ Մոդուլը միանում է Wi-Fi ցանցին և տիրապետում IP կապին՝ ներառյալ իր աղբյուրի հասցեն։ Դարպասը տիրապետում է թունելին, հավատարմագրերին և փոխանցման քաղաքականությանը։ Այս աշխատանքներն առանձին պահելն է, որ նախագիծը դարձնում է վրիպազերծելի յուրաքանչյուր փուլում։
Առանձնացումը փոխում է նաև այն, թե ինչպես եք գրում դարպասի քաղաքականությունը։ Աղբյուրի կանոնը պետք է անվանի մոդուլի LAN հասցեն, այլ ոչ թե սերիական կապի հետևում գտնվող միկրոկարգավորիչի համար հորինված հասցե։ Այս նախագծում միկրոկարգավորիչն իր սեփական IP ինքնությունը չունի, և ձևացնելը, թե ունի, ստեղծում է կանոն, որը երբեք չի համընկնում։
Տվեք մոդուլին կայուն հասցե ցանցի աջակցած ցանկացած վերապահման մեխանիզմով, կամ տեղադրեք սարքերը իրենց սեփական սեգմենտում և թողեք դարպասը համապատասխանեցնի ըստ ինտերֆեյսի։ Վերագործարկումից հետո փոխվող լողավազանի հասցեն ի վերջո կկոտրի քաղաքականություն, որը ճիշտ էր, երբ գրում էիք այն։
Կարո՞ղ է դարպասը անվանել մոդուլի հասցեն։
Նախքան որևէ սոկետ կբացվի, հաստատեք, որ մոդուլը միացված է, ունի հասցե, և որ դարպասը տեսնում է այն սպասվող ինտերֆեյսում։ Սա այն դարպասն է, որ ամենից հաճախ ձախողվում է լուռ, քանի որ մոդուլը սիրով կհայտնի միացման փորձի մասին, որը երբեք չի լքել LAN-ը։
AT+CWMODE=1 AT+CWJAP="lab-wifi","passphrase" AT+CIPSTA? AT+CIPMUX=0
Մեկ կապի ռեժիմը հրամանների հաջորդականությունը պահում է պարզ, և դա ճիշտ մեկնարկային կետն է մեկ սենսորի համար, որը խոսում է մեկ ծառայության հետ։ Բազմակի կապերի ռեժիմը փոխում է յուրաքանչյուր հաջորդ հրամանի շարահյուսությունը, ուստի որոշեք, թե որում եք, նախքան այլ որոնվածի տարբերակից օրինակ պատճենելը։
Բացեք սոկետը մոդուլից
Երբ հասցեն ու ռեժիմը որոշված են, մոդուլը կարող է TCP կապ բացել դեպի մասնավոր ծառայությունը։ Ստորև բերված հասցեն փաստաթղթային տիրույթի օրինակ է, փոխարինեք այն ձերով և պահպանեք նույն ձևը։
AT+CIPSTART="TCP","10.90.0.20",9000
AT+CIPSEND=18
{"t":21.4,"rh":48}
Այդ AT հրամանը բացում է սովորական TCP սոկետ, և սոկետը թունել չէ՝ դրանում ոչինչ VPN չի ստեղծում և ոչինչ չի գաղտնագրում բեռնվածքը։ Որոնվածի TLS ռեժիմը առանձին հատկություն է՝ իր հրամանով և իր սերտիֆիկատների մշակմամբ, և կամայական UART մոդուլը կարող է չաջակցել դրանցից ոչ մեկին։ Փոխարենը ենթադրելու, թե վերևի շարահյուսությունը վերաբերում է դրան, տեսեք ձեր որոնվածի TCP/IP AT հրամանների տեղեկատուն։
AT+CIPSEND-ում բեռնվածքի երկարությունը պետք է համապատասխանի այն, ինչ դուք իրականում ուղարկում եք, այլապես մոդուլը կսպասի բայթերի, որոնք երբեք չեն գա, և կապը կթվա կախված։ Այդ ձախողումը նման է ցանցային խնդրի և գրեթե միշտ երկարության մեջ մեկ միավորի սխալ է։
Անցկացրեք կապը դարպասով
Դարպասին պետք է երթուղի դեպի մասնավոր նպատակակետ, թույլտվություն՝ սարքերի ցանցից թունել փոխանցելու, և վերադարձի ուղի, որը հասնում է մոդուլին։ Եթե հեռավոր կողմը հետ չի երթուղավորում դեպի սարքերի ենթացանց, նախագիծը կարիք ունի դիտավորյալ թարգմանության կանոնի, և այդ կանոնը փոխում է աղբյուրի ինքնությունը, որը տեսնում է ծառայությունը։
ip route get 10.90.0.20 sudo tcpdump -ni wg0 'host 10.90.0.20 and port 9000' sudo conntrack -L | grep 9000
Նախ հետևեք վերադարձի ուղուն։ Փոխանցված փաթեթը, որը հասնում է ծառայությանը և երբեք չի վերադառնում, մոդուլում առաջացնում է ժամանակի սպառում առանց դարպասի վրա որևէ սխալի, ինչը մարդկանց ժամերով նայել է տալիս Wi-Fi կապին։ conntrack գրառումը ձեզ ասում է, թե դարպասը տեսել է պատասխանն ընդհանրապես։
Որոշեք, թե որտեղ է իրականում ավարտվում թունելը
Թունելը սկսվում է դարպասից։ Այն չի գաղտնագրում UART կապը, և մոդուլի ու դարպասի միջև LAN սեգմենտը թունելի մաս չի դարձնում։ Այդ սեգմենտում պաշտպանության կարիք ունեցող ամեն ինչ իր սեփական մեխանիզմի կարիքն ունի, և այս օրինակի սովորական TCP-ն TLS չէ։
Որոշեք նաև, թե ինչ է լինում, երբ թունելն ընկնում է։ Եթե առաքումը պետք է լինի միայն VPN-ով, փոխանցման քաղաքականությունը չպետք է թույլ տա նույն նպատակակետը այլընտրանքային ուղիով, քանի որ պահուստային երթուղին լուռ զրոյացնում է պահանջը։ Սահմանափակեք վերսկսման վարքը, որպեսզի անջատված մոդուլը չհեղեղի սերիական կապը կամ հեռավոր ծառայությունը կրկնվող փորձերով։
Գրի առեք չորս պատասխանները միասին՝ մոդուլի հասցեն, սոկետի նպատակը, դարպասի երթուղին և այն, թե որտեղից է սկսվում գաղտնագրումը։ Հաջորդ մարդը, ով կվրիպազերծի այս սարքը, կարիք կունենա բոլոր չորսին, և դրանցից ոչ մեկը հնարավոր չէ եզրակացնել միայն որոնվածից։