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