Три одлуки за адреси пред да ставите IoT сензори зад VPN

Три адреси се заплеткуваат во секој план за IoT преку VPN и тие не се ист вид одлука. Едната е како далечински оператор го наоѓа крајот на тунелот, другата е како локацијата докажува дека е локацијата, а третата е каде услугата на сензорот навистина слуша. Одговорете по тој редослед и дизајнот главно излегува сам. Одговорете како на едно прашање и ќе завршите со доделување јавни адреси на уреди на кои никогаш не им требале. Сензор зад излезен тунел на локацијата е достапен за овластен оператор без ниту едно влезно правило насочено кон сензорот.

Започнете со тоа кој иницира

Кој се јавува одредува речиси се понатаму. Кога локацијата се јавува на хаб, на локацијата не ѝ треба влезна достапност, а на хаб му треба име или адреса што локацијата може да ја реши. Овој единствен избор го отстранува најголемиот дел од дебатата за статично јавно адресирање пред таа да започне.

Трите улоги потоа чисто се раздвојуваат, а табелата подолу е најкратката форма на одлуката.

Секој ред има различен сопственик и тоа е вистинската поента. Хаб му припаѓа на тој што ја води VPN услугата, парот на локацијата на мрежниот тим, а адресата на сензорот на тој што го поседува уредот.

Адресата на хаб е почеток, а не дестинација

Име што се решава во одржувана јавна адреса е доволно за хаб. DNS записот може да го следи крајот кога тој се преместува, без рачно уредување на секоја конфигурација на локацијата. Она што DNS не го прави е да создава достапност или да освежува клиент што ја кешира старата адреса, и тие се одделни проблеми со одделни решенија.

Ако водите тунели локација-до-локација без хаб, истата логика важи во друга форма: едната страна треба достапен крај, или двете страни се јавуваат на трета страна. Некој сепак мора да ја поседува таа адреса и нејзините обновувања.

Парот на локацијата е идентитет со прикачен префикс

Парот е прво идентитет, а второ префикс. Во термини на WireGuard парот држи пар клучеви, а записот AllowedIPs на хаб го врзува тој клуч за префиксот на локацијата. Во термини на IKEv2 сертификат или однапред споделен клуч ја идентификува локацијата, а нејзините селектори на сообраќај кажуваат што смее да носи. Менувањето само на едната половина ја крши поставеноста, затоа промената на адреса никогаш не смее да се третира како промена на идентитет.

Држете го сопствеништвото на клучот или сертификатот кај локацијата, а не кај операторот на хаб, за да не стане промената на провајдер промена на идентитет.

Префиксот е делот што луѓето забораваат да го планираат. Хаб мора да ја поврзе подмрежата на сензорот со правилниот пар, а клиентот на операторот му треба маршрута до неа; маршрута што постои само на клиентот испраќа сообраќај во тунел што тивко го отфрла. Запишете го префиксот во записот на локацијата покрај отпечатокот на клучот, за да не може заменета порта да се појави со различно покривање без никој да забележи.

Адресата на сензорот му припаѓа на апликацијата

Приватна адреса од планот на локацијата е доволна, а ѝ треба стабилност, а не јавна достапност: DHCP резервација, статична додела или име во сопствената зона на локацијата. Ако уредот не може да се пренумерира, преводот на портата на локацијата е легитимен одговор додека преводот е документиран и повратниот сообраќај го следи.

Уште една навика што вреди да се задржи: никогаш не лепете ја јавната адреса на хаб во поле за следен скок на домаќинот на сензорот. VPN го поставува својот пат, а обичната Ethernet соседност со јавен крај е фикција што создава убедливо изгледна конфигурација.

Одговорите се половината што се прескокнува. Уредот мора да го испрати својот одговор назад кон тунелот, или преку маршрута до клиентот на операторот или преку истата порта што го превела барањето. Сензор со погрешна стандардна порта го прифаќа барањето и одговара во ништо, а белешките за препраќање објаснуваат зошто пристигнувањето и насочувањето на одговорот се два барања, а не едно.

Одлучете, потоа запишете ја границата

Запишете ја границата на пристап пред некој да се поврзе. Ограничете ја портата на IoT сегментот и на конкретните услуги што му требаат на операторот, бидејќи работечката маршрута лесно станува општ пристап по грешка. Држете го набљудувањето само за читање и овластувањето за конфигурација како одделни улоги со одделни идентитети и именувајте ја личноста што го отстранува пристапот кога договорот ќе заврши.

Одобрувањето му припаѓа на сопственикот на мрежата, а тоа што сте во DMZ не е политика за пристап.

Тестот по распоредувањето е досаден и решавачки: едно барање во дозволениот префикс што успева, бројач што расте на портата и еден намерен обид надвор од префиксот што не успева.