วาง VPN ไว้หลังโมดูล Wi-Fi UART ไม่ใช่ข้างใน

ไมโครคอนโทรลเลอร์ที่ใช้โมดูล Wi-Fi UART ไม่จำเป็นต้องติดตั้ง 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 ทั่วไปอาจไม่รองรับทั้งสองอย่าง ตรวจดู เอกสารอ้างอิงคำสั่ง AT สำหรับ TCP/IP ของเฟิร์มแวร์คุณ แทนที่จะถือว่าไวยากรณ์ข้างต้นใช้กับมัน

ความยาวเพย์โหลดใน 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 เท่านั้น นโยบายการส่งต่อต้องไม่อนุญาตปลายทางเดียวกันผ่านเส้นทางสำรอง เพราะเส้นทางสำรองจะล้มล้างข้อกำหนดอย่างเงียบ ๆ จำกัดพฤติกรรมการเชื่อมต่อใหม่เพื่อให้โมดูลที่หลุดไม่ท่วมลิงก์อนุกรมหรือบริการระยะไกลด้วยการลองซ้ำ

บันทึกคำตอบทั้งสี่ไว้ด้วยกัน ที่อยู่ของโมดูล ปลายทางของซ็อกเก็ต เส้นทางของเกตเวย์ และจุดที่การเข้ารหัสเริ่มต้น คนถัดไปที่แก้จุดบกพร่องอุปกรณ์นี้จะต้องใช้ทั้งสี่ข้อ และไม่มีข้อใดอนุมานได้จากเฟิร์มแวร์เพียงอย่างเดียว