Три решения за адресите, преди да поставите 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 не е политика за достъп.
Тестът след внедряването е скучен и решителен: една заявка в разрешения префикс, която успява, брояч, който се увеличава на шлюза, и един умишлен опит извън префикса, който се проваля.