Три рішення про адреси, перш ніж ставити датчики 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 — не політика доступу.
Перевірка після розгортання нудна й вирішальна: один запит усередині дозволеного префікса, який проходить, лічильник, що зростає на шлюзі, і одна навмисна спроба поза префіксом, яка зазнає невдачі.