הציבו את ה-VPN מאחורי מודול Wi-Fi עם UART, לא בתוכו

בקר מיקרו עם מודול Wi-Fi של UART אינו צריך לממש VPN כדי להגיע לשירות שנמצא מאחוריו. המודול כבר מריץ מחסנית TCP/IP וחושף שקעים דרך היציאה הטורית, ושער באותה רשת מקומית יכול להעביר את התעבורה הזו דרך המנהרה. התכנון עובד רק אם אתם יכולים לענות על ארבע שאלות לפי הסדר, אז התייחסו אליו כרשימת בדיקה: כתובת, שקע, מסלול, גבול. עצרו בשער הראשון שנכשל, כי השערים שאחריו אינם יכולים לפצות עליו.

הקצו תפקיד אחד לכל שכבה

קישור ה-UART מעביר פקודות AT ומטען בין בקר המיקרו למודול. המודול מצטרף לרשת ה-Wi-Fi ומחזיק בחיבור ה-IP, כולל כתובת המקור שלו. השער מחזיק במנהרה, באישורים ובמדיניות ההעברה. הפרדת התפקידים האלה היא מה שהופך את התכנון לניתן לבדיקה בכל שלב.

ההפרדה משנה גם את הדרך שבה כותבים את מדיניות השער. כלל מקור צריך לנקוב בכתובת ה-LAN של המודול, ולא בכתובת דמיונית לבקר המיקרו שמאחורי הקישור הטורי. לבקר המיקרו אין זהות 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 אקראי אינו תומך באף אחד מהם. ראו את מדריך פקודות ה-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 בלבד, מדיניות ההעברה לא תאפשר את אותו יעד דרך נתיב חלופי, כי נתיב גיבוי מבטל את הדרישה בשקט. הגבילו את התנהגות ההתחברות מחדש כדי שמודול מנותק לא יציף את הקישור הטורי או את השירות המרוחק בניסיונות חוזרים.

רשמו את ארבע התשובות יחד: כתובת המודול, יעד השקע, המסלול של השער והיכן מתחילה ההצפנה. האדם הבא שיאבחן את ההתקן הזה יזדקק לכל הארבע, ואף אחת מהן אינה ניתנת להסקה מהקושחה בלבד.