UART Wi-Fi મોડ્યુલ ધરાવતા માઇક્રોકંટ્રોલરને તેની પાછળની સેવા સુધી પહોંચવા માટે VPN લાગુ કરવાની જરૂર નથી. મોડ્યુલ પહેલેથી જ TCP/IP સ્ટેક ચલાવે છે અને સીરિયલ પોર્ટ પર સોકેટ આપે છે, અને એ જ લાન પરનું ગેટવે તે ટ્રાફિક ટનલમાંથી લઈ જઈ શકે છે. આ ડિઝાઇન ત્યારે જ કામ કરે છે જ્યારે તમે ચાર પ્રશ્નોના ક્રમમાં જવાબ આપી શકો, તેથી તેને ચેકલિસ્ટ તરીકે લો: સરનામું, સોકેટ, માર્ગ, સીમા. જે પહેલું દ્વાર નિષ્ફળ જાય ત્યાં અટકો, કારણ કે પછીનાં તેની ભરપાઈ કરી શકતાં નથી.

દરેક સ્તરને એક કામ આપો

UART કડી માઇક્રોકંટ્રોલર અને મોડ્યુલ વચ્ચે AT આદેશો અને પેલોડ વહન કરે છે. મોડ્યુલ Wi-Fi નેટવર્કમાં જોડાય છે અને તેના સ્રોત સરનામા સહિત IP જોડાણનું માલિક છે. ગેટવે ટનલ, ઓળખપત્રો અને ફોરવર્ડિંગ નીતિનું માલિક છે. આ કામો અલગ રાખવાથી જ ડિઝાઇન દરેક તબક્કે ડિબગ કરી શકાય તેવી બને છે.

આ અલગીકરણ ગેટવે નીતિ કેવી રીતે લખો છો તે પણ બદલે છે. સ્રોત નિયમમાં મોડ્યુલનું લાન સરનામું હોવું જોઈએ, સીરિયલ કડી પાછળના માઇક્રોકંટ્રોલર માટેનું કાલ્પનિક સરનામું નહીં. આ ડિઝાઇનમાં માઇક્રોકંટ્રોલરની પોતાની કોઈ IP ઓળખ નથી, અને એવું હોવાનું ઢોંગ કરવાથી એવો નિયમ બને છે જે ક્યારેય મળતો નથી.

નેટવર્ક જે પણ રિઝર્વેશન પદ્ધતિ ટેકો આપે તેના દ્વારા મોડ્યુલને સ્થિર સરનામું આપો, અથવા ઉપકરણોને તેમના પોતાના સેગમેન્ટમાં મૂકો અને ગેટવેને ઇન્ટરફેસ પ્રમાણે મેળવવા દો. રીબૂટ પછી બદલાતું પૂલ સરનામું આખરે એ નીતિ તોડી નાખશે જે લખતી વખતે સાચી હતી.

શું ગેટવે મોડ્યુલનું સરનામું નામ આપી શકે?

કોઈ પણ સોકેટ ખૂલે તે પહેલાં ખાતરી કરો કે મોડ્યુલ જોડાયેલું છે, તેનું સરનામું છે અને ગેટવે તેને અપેક્ષિત ઇન્ટરફેસ પર જુએ છે. આ એ દ્વાર છે જે સૌથી વધુ ચૂપચાપ નિષ્ફળ જાય છે, કારણ કે મોડ્યુલ ખુશીથી એવા જોડાણ પ્રયાસની જાણ કરશે જે કદી લાન છોડ્યો જ નહોતો.

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 કડીને એન્ક્રિપ્ટ કરતું નથી, અને મોડ્યુલથી ગેટવે સુધીના લાન સેગમેન્ટને ટનલનો ભાગ બનાવતું નથી. એ સેગમેન્ટ પર જેને પણ સુરક્ષા જોઈએ તેને પોતાની પદ્ધતિ જોઈએ, અને આ ઉદાહરણમાં સાદું TCP એ TLS નથી.

ટનલ પડી જાય ત્યારે શું થાય તે પણ નક્કી કરો. જો ડિલિવરી ફક્ત VPN દ્વારા જ થવી જોઈએ, તો ફોરવર્ડિંગ નીતિએ વૈકલ્પિક માર્ગે એ જ ગંતવ્યને મંજૂરી આપવી ન જોઈએ, કારણ કે ફોલબેક માર્ગ શરતને ચૂપચાપ નિષ્ફળ બનાવે છે. પુનઃજોડાણનું વર્તન મર્યાદિત કરો જેથી કપાયેલું મોડ્યુલ સીરિયલ કડી કે દૂરની સેવાને ફરી પ્રયાસોથી ભરી ન દે.

ચાર જવાબો એકસાથે નોંધો: મોડ્યુલનું સરનામું, સોકેટનું લક્ષ્ય, ગેટવેનો માર્ગ અને એન્ક્રિપ્શન ક્યાં શરૂ થાય છે. આ ઉપકરણને પછી ડિબગ કરનાર વ્યક્તિને ચારેયની જરૂર પડશે, અને એમાંથી એક પણ ફક્ત ફર્મવેર પરથી અનુમાન કરી શકાતું નથી.

સંબંધિત લેખો