سه تصمیم درباره نشانی پیش از قرار دادن حسگرهای اینترنت اشیا پشت VPN
سه نشانی سه نقش دارند: هاب عمومی، همتای احرازشده سایت و نشانی خصوصی حسگر. پیش از تخصیص هر چیز عمومی، هر یک را برنامه‌ریزی کنید.
سه نشانی در هر طرح اینترنت اشیا روی 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 مسیر خودش را نصب می‌کند و همسایگی معمولی اترنت با یک نقطه پایانی عمومی خیالی است که پیکربندی باورپذیر می‌سازد.
پاسخ‌ها همان نیمه‌ای هستند که از قلم می‌افتند. دستگاه باید پاسخ خود را به سمت تونل بازگرداند، یا از طریق مسیری به کلاینت اپراتور یا از طریق همان دروازه‌ای که درخواست را ترجمه کرده است. حسگری با دروازه پیش‌فرض اشتباه درخواست را می‌پذیرد و به هیچ‌جا پاسخ می‌دهد، و یادداشت‌های ارسال توضیح می‌دهند چرا رسیدن و مسیریابی پاسخ دو الزام است نه یکی.
تصمیم بگیرید، سپس مرز را بنویسید
مرز دسترسی را پیش از آنکه کسی وصل شود بنویسید. دروازه را به بخش اینترنت اشیا و به سرویس‌های مشخصی که اپراتور نیاز دارد محدود کنید، زیرا مسیر کارکننده به‌طور تصادفی به دسترسی عمومی تبدیل می‌شود. پایش فقط‌خواندنی و اختیار پیکربندی را نقش‌های جدا با هویت‌های جدا نگه دارید و نام کسی را بنویسید که با پایان قرارداد دسترسی را برمی‌دارد.
تأیید از آن مالک شبکه است و بودن در DMZ سیاست دسترسی نیست.
آزمون پس از استقرار خسته‌کننده و قاطع است: یک درخواست درون پیشوند مجاز که موفق می‌شود، شمارنده‌ای که روی دروازه بالا می‌رود، و یک تلاش عمدی بیرون پیشوند که شکست می‌خورد.