Тры рашэнні пра адрасы, перш чым ставіць датчыкі 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 — не палітыка доступу.
Тэст пасля разгортвання нудны і вырашальны: адзін запыт унутры дазволенага прэфікса, які паспяхова выконваецца, лічыльнік, які павялічваецца на шлюзе, і адна наўмысная спроба па-за прэфіксам, якая правальваецца.