שלוש החלטות כתובת לפני שמציבים חיישני IoT מאחורי VPN
שלוש כתובות ממלאות שלושה תפקידים: הרכז הציבורי, עמית האתר המאומת וכתובתו הפרטית של החיישן. תכננו כל אחת לפני הקצאת משהו ציבורי.
שלוש כתובות מסתבכות בכל תוכנית IoT מעל VPN, והן אינן אותו סוג של החלטה. האחת היא איך מפעיל מרוחק מוצא את נקודת הקצה של המנהרה, השנייה היא איך האתר מוכיח שהוא האתר, והשלישית היא היכן שירות החיישן באמת מאזין. ענו עליהן בסדר הזה והתכנון כמעט יוצא מעצמו. ענו עליהן כשאלה אחת ואז תגיעו למצב של הקצאת כתובות ציבוריות להתקנים שמעולם לא נזקקו לאחת. חיישן מאחורי מנהרת אתר יוצאת נגיש למפעיל מורשה בלי שום כלל נכנס שמצביע על החיישן.
התחילו בשאלה מי יוזם
מי מחייג קובע כמעט הכול בהמשך. כשהאתר מחייג אל רכז, האתר אינו זקוק לנגישות נכנסת, והרכז זקוק לשם או לכתובת שהאתר יכול לפתור. הבחירה האחת הזאת מסירה את רוב הוויכוח על מיעון ציבורי סטטי לפני שהוא מתחיל.
שלושת התפקידים נפרדים אז באופן נקי, והטבלה שלמטה היא הצורה הקצרה ביותר של ההחלטה.
| Decision | What you are actually choosing | Usual default |
|---|---|---|
| Hub endpoint | How the tunnel service is published | A DNS name, no inbound rule toward the site |
| Site peer | How the site proves its identity and which prefixes it carries | One key pair or certificate per site, prefix in the tunnel config |
| Sensor service | How the application is addressed inside the site | A stable private address from the site plan |
לכל שורה בעלים אחר, וזו הנקודה האמיתית. הרכז שייך למי שמפעיל את שירות ה-VPN, עמית האתר לצוות הרשת, וכתובת החיישן למי שמחזיק בהתקן.
כתובת הרכז היא אתחול, לא יעד
שם שנפתר לכתובת ציבורית מתוחזקת מספיק לרכז. רשומת DNS יכולה לעקוב אחר נקודת הקצה כשהיא עוברת, בלי לערוך ידנית כל תצורת אתר. מה ש-DNS לא עושה הוא ליצור נגישות או לרענן לקוח ששומר את התשובה הישנה, ואלה בעיות נפרדות עם פתרונות נפרדים.
אם אתם מפעילים מנהרות אתר-לאתר בלי רכז, אותו היגיון תקף בצורה אחרת: צד אחד זקוק לנקודת קצה נגישה, או ששני הצדדים מחייגים לצד שלישי. מישהו עדיין צריך להחזיק בכתובת הזאת ובחידושיה.
עמית האתר הוא זהות עם קידומת מחוברת
העמית הוא קודם זהות ואחר כך קידומת. במונחי WireGuard העמית מחזיק זוג מפתחות והרשומה AllowedIPs של הרכז קושרת את המפתח הזה לקידומת של האתר. במונחי IKEv2 תעודה או מפתח משותף מראש מזהים את האתר ובוררי התעבורה שלו אומרים מה הוא רשאי לשאת. שינוי של חצי אחד בלבד שובר את הסידור, ולכן אסור להתייחס לשינוי כתובת כאל שינוי זהות.
החזיקו את הבעלות על המפתח או התעודה באתר ולא אצל מפעיל הרכז, כדי שהחלפת ספק לא תהפוך להחלפת זהות.
הקידומת היא החלק שאנשים שוכחים לתכנן. הרכז חייב לשייך את תת-הרשת של החיישן לעמית הנכון, והלקוח של המפעיל זקוק למסלול אליה; מסלול שקיים רק בלקוח שולח תעבורה לתוך מנהרה שפשוט מפילה אותה בשקט. כתבו את הקידומת ברשומת האתר לצד טביעת האצבע של המפתח, כדי ששער חלופי לא יוכל לעלות עם כיסוי שונה בלי שאיש ישים לב.
כתובת החיישן שייכת ליישום
כתובת פרטית מתוכנית האתר מספיקה, ומה שהיא צריכה הוא יציבות ולא נגישות ציבורית: הקצאה קבועה ב-DHCP, שיוך סטטי, או שם באזור של האתר עצמו. אם אי אפשר למספר את ההתקן מחדש, תרגום בשער האתר הוא תשובה לגיטימית כל עוד התרגום מתועד ותעבורת החזרה הולכת אחריו.
הרגל נוסף ששווה לשמור: לעולם אל תדביקו את הכתובת הציבורית של הרכז בשדה הצעד הבא במארח של החיישן. ה-VPN מתקין מסלול משלו, וסמיכות Ethernet רגילה לנקודת קצה ציבורית היא בדייה שמייצרת תצורה שנראית משכנעת.
התשובות הן החצי שמדלגים עליו. ההתקן חייב לשלוח את תשובתו חזרה לכיוון המנהרה, או דרך מסלול ללקוח של המפעיל או דרך אותו שער שתרגם את הבקשה. חיישן עם שער ברירת מחדל שגוי מקבל את הבקשה ועונה לשום מקום, ואילו הערות ההעברה מסבירות מדוע הגעה וניתוב תשובה הם שני דרישות ולא אחת.
החליטו, ואז כתבו את הגבול
כתבו את גבול הגישה לפני שמישהו מתחבר. הגבילו את השער למקטע ה-IoT ולשירותים הספציפיים שהמפעיל צריך, כי מסלול שעובד נוטה להפוך לגישה כללית בטעות. החזיקו ניטור לקריאה בלבד וסמכות תצורה כתפקידים נפרדים עם זהויות נפרדות, ונקבו בשם האדם שמסיר את הגישה כשהחוזה מסתיים.
האישור שייך לבעל הרשת, ולהיות ב-DMZ אינו מדיניות גישה.
הבדיקה אחרי הפריסה משעממת ומכרעת: בקשה אחת בתוך הקידומת המותרת שמצליחה, מונה שעולה בשער, וניסיון מכוון אחד מחוץ לקידומת שנכשל.