VPN UART Wi-Fi მოდულის უკან მოათავსეთ და არა მის შიგნით

მიკროკონტროლერს 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

ერთი კავშირის რეჟიმი ბრძანებათა მიმდევრობას მარტივს ინახავს და სწორი საწყისი წერტილია ერთი სენსორისთვის, რომელიც ერთ სერვისს ესაუბრება. მრავალი კავშირის რეჟიმი ცვლის ყოველი შემდგომი ბრძანების სინტაქსს, ამიტომ სანამ სხვა firmware ვერსიიდან მაგალითს დააკოპირებთ, გადაწყვიტეთ რომელ რეჟიმში ხართ.

გახსენით სოკეტი მოდულიდან

მისამართისა და რეჟიმის დადგენის შემდეგ მოდულს შეუძლია კერძო სერვისთან TCP კავშირი გახსნას. ქვემოთ მოცემული მისამართი დოკუმენტაციის დიაპაზონის მაგალითია; ჩაანაცვლეთ იგი თქვენით და შეინარჩუნეთ იგივე ფორმა.

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

ის AT ბრძანება ჩვეულებრივ TCP სოკეტს ხსნის და სოკეტი გვირაბი არ არის: მასში არაფერი ქმნის VPN-ს და არაფერი შიფრავს დატვირთვას. firmware-ის TLS რეჟიმი ცალკე თვისებაა, საკუთარი ბრძანებითა და სერთიფიკატების საკუთარი დამუშავებით, და თვითნებურ UART მოდულს შეიძლება არც ერთი მათგანი არ ჰქონდეს. იმის ნაცვლად, რომ ივარაუდოთ ზემო სინტაქსის მოქმედება, ნახეთ თქვენი firmware-ის 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-ით უნდა მოხდეს, გადაგზავნის პოლიტიკამ არ უნდა დაუშვას იგივე დანიშნულება ალტერნატიული გზით, რადგან სარეზერვო მარშრუტი ჩუმად აუქმებს მოთხოვნას. შეზღუდეთ ხელახალი დაკავშირების ქცევა, რომ გათიშულმა მოდულმა სერიული კავშირი ან შორეული სერვისი განმეორებითი ცდებით არ დატბოროს.

ოთხივე პასუხი ერთად ჩაწერეთ: მოდულის მისამართი, სოკეტის დანიშნულება, კარიბჭის მარშრუტი და სად იწყება დაშიფვრა. შემდეგ ადამიანს, ვინც ამ მოწყობილობის გამართვას მოახდენს, ოთხივე დასჭირდება, და არც ერთი მათგანი მხოლოდ firmware-იდან არ გამომდინარეობს.