برای سراسر شبکه خانگی‌ام سازوکاری برای پاسداری از حریم خصوصی دارم که تا وقتی به مشکل نخورد، بی‌نقص کار می‌کند. Pi-hole ردیاب‌ها را در لپ‌تاپ‌ها و گوشی‌هایم مسدود می‌کرد، اما همان فهرست‌های سخت‌گیرانه گاهی تلویزیون‌های هوشمند را از کار می‌انداختند، اعلان دوربین‌ها را به تأخیر می‌انداختند یا لامپی وابسته به فضای ابری را از اینترنت جدا می‌کردند.
در نتیجه، مدام در چرخه‌ای گرفتار بودم: یک نام میزبان ناشناخته را مجاز می‌کردم، دوباره آزمایش می‌کردم و این کار را آن‌قدر تکرار می‌کردم تا دستگاه بار دیگر برخط شود. پس تصمیم گرفتم برای شبکه خانه هوشمندم سیاست DNS جداگانه‌ای در نظر بگیرم؛ کشمکش همیشگی هم یک‌شبه پایان یافت.
Pi-hole همه‌چیز را مسدود می‌کند؛ حتی انگیزه لامپ هوشمندتان برای زنده ماندن را
گوشی خطا را نشان می‌دهد؛ لامپ بی‌سروصدا تسلیم می‌شود
مشکل از خود مسدودسازی DNS نبود. پالایه‌های سطح DNS برای دستگاه‌هایی که نمی‌توانند افزونه مرورگر یا برنامه‌های پاسداری از حریم خصوصی را اجرا کنند بسیار کارآمدند؛ زیرا حل‌کننده می‌تواند از بازگرداندن نشانی دامنه‌های ردیاب یا مخرب خودداری کند و اتصال را پیش از آغاز متوقف سازد. Pi-hole و AdGuard Home این حفاظت را بی‌نیاز از نصب نرم‌افزار روی دستگاه‌های کارخواه، در سراسر شبکه برقرار می‌کنند و به همین دلیل برای دستگاه‌های IoT بسیار سودمندند.
بااین‌حال، اگر یک سیاست یکسان و فراگیر را برای همه دستگاه‌ها به کار ببرید، به مشکل برمی‌خورید. گوشی من فهرست‌های مسدودسازی سخت‌گیرانه را تاب می‌آورد، چون می‌توانم خطا را ببینم، گزارش درخواست‌ها را بررسی کنم و راهی برای دور زدن مشکل بیابم. اما لامپ هوشمند نمی‌تواند توضیح دهد که نقطه پایانی ورود، میزبان داده‌های پایشی و سرویس فرمان آن پشت دامنه‌های مرتبط با یکدیگر قرار دارند. اگر هرکدام از این دامنه‌ها مسدود شود، لامپ دیگر پاسخ نمی‌دهد. آسان‌گیرتر کردن پالایه‌ها برای همه دستگاه‌ها، لامپ را دوباره برخط می‌کند؛ اما امنیت دستگاه‌هایی را کاهش می‌دهد که از ابتدا از فهرست‌های سخت‌گیرانه‌تر سود می‌بردند.
خانه هوشمند مسیر DNS خودش را می‌گیرد و آشفتگی پایان می‌یابد
دستگاه‌های متفاوت، سیاست‌های متفاوت؛ اگر تنبلید، با همان سخت‌افزار
راه‌حل من این بود که دستگاه‌های خانه هوشمند را رده‌ای جداگانه در نظر بگیرم. آنها از پیش روی شبکه‌ای جداشده با فرکانس ۲.۴ GHz قرار داشتند، بنابراین یک حل‌کننده اختصاصی DNS به آن شبکه دادم. در اینجا داشتن سرور فیزیکی جداگانه ضروری نیست؛ یک محفظه، ماشین مجازی یا نمونه دیگر از Pi-hole یا AdGuard Home روی سخت‌افزار موجود نیز به همان خوبی کار می‌کند. تفاوت اصلی در سیاست است، نه سرویسی که آن را اجرا می‌کند.
سرویس DHCP روتر، حل‌کننده IoT را فقط به دستگاه‌های همان شبکه معرفی می‌کند؛ درحالی‌که شبکه مورداعتماد من همچنان از حل‌کننده سخت‌گیرانه‌تر بهره می‌برد. Pi-hole همچنین می‌تواند دستگاه‌های کارخواه را به گروه‌هایی با فهرست‌ها و قواعد متفاوت اختصاص دهد؛ بنابراین اگر حل‌کننده بتواند هر دستگاه را با اطمینان شناسایی کند، دستیابی به همین نتیجه با یک نمونه نیز ممکن است. AdGuard Home نیز از تنظیمات ویژه هر دستگاه و حل‌کننده‌های بالادستی مختص هر دامنه پشتیبانی می‌کند.
این جداسازی، یک حالت پیش‌فرض معقول در اختیارتان می‌گذارد. رایانه‌ها و گوشی‌ها همچنان از حفاظت سخت‌گیرانه در برابر تبلیغات، بدافزارها و ردیاب‌ها بهره می‌برند؛ در مقابل، دستگاه‌های خانه هوشمند فهرست مسدودسازی کوچک‌تر و امنیت‌محوری دریافت می‌کنند که دامنه‌های آزموده‌شده داده‌های پایشی را نیز، در صورتی که باعث اختلال در دستگاه‌ها نشوند، به‌صراحت مسدود می‌کند. اگر نقطه پایانی یک سازنده برای راه‌اندازی، احراز هویت، اعلان‌ها یا بررسی میان‌افزار ضروری باشد، آن را فقط در سیاست IoT مجاز می‌کنم. دیگر برای زنده کردن یک پریز هوشمند بدقلق مجبور نیستم در سراسر شبکه رخنه ایجاد کنم.
وقتی گزارش درخواست‌ها فقط به ابزارهای هوشمند مربوط باشد، سرانجام به کار می‌آید
دامنه ضروری پریز هوشمند را پیدا کنید و دست از حدس زدن بردارید
بزرگ‌ترین دردسر این روش آن است که هیچ فهرست مسدودسازی همگانی و آماده‌ای در اینترنت وجود ندارد که بتوانید بارگیری و همین‌جا استفاده کنید. دامنه‌هایی که در نهایت مسدود می‌کنید، به دستگاه‌های هوشمند موجود در خانه‌تان بستگی دارند؛ بنابراین باید گزارش‌ها را زیرورو کنید. مزیت کار این است که به‌جای جست‌وجو میان هزاران درخواست مرورگرها، برنامه‌ها و سیستم‌عامل‌ها، دقیقاً می‌بینید دستگاه‌های هوشمندتان هم‌زمان با از کار افتادن یک قابلیت چه نشانی‌هایی را درخواست کرده‌اند. سپس می‌توانید پالایش را موقتاً برای همان دستگاه غیرفعال کنید، مشکل را دوباره پدید آورید، نتیجه‌ها را بسنجید و فقط کمترین شمار دامنه‌های ضروری را مجاز کنید.
البته این به معنای مخرب بودن همه درخواست‌ها نیست و ثابت نمی‌کند دستگاه چه داده‌هایی می‌فرستد. DNS نام میزبان‌هایی را آشکار می‌کند که دستگاه می‌کوشد به آنها دسترسی یابد، نه محتوای یک اتصال رمزگذاری‌شده را. بااین‌همه، کوچک‌تر بودن مجموعه داده‌ها الگوها را نمایان می‌کند؛ برای نمونه، جست‌وجوهای پی‌درپی مربوط به داده‌های پایشی، سرویس‌های شخص ثالث پیش‌بینی‌نشده یا دستگاهی که حتی هنگام کنترل محلی نیز همچنان با فضای ابری تماس می‌گیرد. پالایش DNS می‌تواند نقطه کنترلی سودمندی باشد، اما جایگزین قواعد LAN و محدودیت‌های دیواره آتش برای ارتباطات خروجی نیست؛ بلکه آنها را تکمیل می‌کند.
نام‌ها بهتر از عددها هستند: ha.home.arpa به‌جای ۱۹۲.۱۶۸.something
RFC ۸۳۷۵ برای LAN شما پسوندی تعیین کرد؛ .local را کنار بگذارید
یکی از مزیت‌های جانبی راه‌اندازی یک حل‌کننده اختصاصی برای خانه هوشمند این بود که آن را مرجع نام‌های داخلی هم قرار دادم. به‌این‌ترتیب، دیگر برای دسترسی به هر سرویس مجبور نیستم هر بار نشانی IP و شماره درگاه را وارد کنم و می‌توانم از نشانی‌هایی مانند ha.home.arpa برای Home Assistant، نشانی mqtt.home.arpa برای کارگزار MQTT و موارد مشابه بهره ببرم. Pi-hole و AdGuard Home هر دو از رکوردهای محلی یا بازنویسی DNS برای نگاشت نام میزبان به نشانی شبکه محلی پشتیبانی می‌کنند.
انتخاب home.arpa عمدی بود. استاندارد RFC ۸۳۷۵ این دامنه را برای نام‌گذاری غیریکتا در شبکه‌های خانگی کنار گذاشته و تصریح می‌کند که درخواست‌های مربوط به آن باید در همان شبکه پاسخ داده شوند، نه اینکه به اینترنت فرستاده شوند. این انتخاب هم مرا از دردسر ساختن یک پسوند تازه نجات داد و هم بار اضافی بر دوش .local نگذاشت؛ دامنه‌ای که به DNS چندپخشی تعلق دارد و قرار است در پیوند محلی و از راه mDNS تفکیک شود.
نام‌گذاری داخلی همچنین نشانی‌های IP ثابت و تعبیه‌شده را از داشبوردها، اسکریپت‌ها و یکپارچه‌سازی‌های Home Assistant حذف کرد. اگر سرویسی را به میزبان دیگری منتقل کنم، به‌جای جست‌وجو در انبوه پرونده‌های پیکربندی فقط یک رکورد DNS را تغییر می‌دهم. بازنویسی DNS می‌تواند تفکیک افق را نیز فراهم کند؛ یعنی یک نام میزبان عمومی در خانه به نشانی خصوصی و در جاهای دیگر به نشانی عمومی خود تفکیک شود. این الگویی رایج در راه‌اندازی‌های Home Assistant است.
تبریک؛ حالا زیرساختی حیاتی را می‌گردانید
پشتیبان‌گیری، حل‌کننده دوم و دستگاه‌های اینترنت اشیا که باز هم ساز خودشان را می‌زنند
بزرگ‌ترین ایراد این رویکرد آن است که یک حل‌کننده اختصاصی خیلی زود به زیرساختی تبدیل می‌شود که نگهداری‌اش بر عهده خودتان است. چنین سامانه‌ای به نشانی ثابت، نسخه پشتیبان، فضای ذخیره‌سازی زیر نظر و ترجیحاً یک حل‌کننده دوم نیاز دارد. معرفی یک حل‌کننده عمومی به‌عنوان گزینه ثانویه، راهکار پاکیزه‌ای برای جابه‌جایی هنگام خرابی نیست؛ زیرا دستگاه‌های کارخواه ممکن است از هرکدام از دو کارساز استفاده کنند و در نتیجه پالایش محلی یا نام‌های داخلی را دور بزنند. بنابراین، هر دو نشانی اعلام‌شده باید سیاست محلی یکسانی را اعمال کنند.
برخی محصولات اینترنت اشیا نیز از حل‌کننده‌های ثابت و تعبیه‌شده یا DNS رمزگذاری‌شده استفاده می‌کنند. سرانجام برای مدیریت درخواست‌های معمول DNS به بیرون، قواعدی در دیواره آتش ساختم که درگاه ۵۳ را در شبکه محلی اینترنت اشیا تغییر مسیر می‌دهند یا مسدود می‌کنند؛ اما DNS رمزگذاری‌شده به مهارهای سنجیده‌تری نیاز دارد و جدا کردنش از ترافیک عادی HTTPS می‌تواند دشوار باشد. IPv6 نیز به توجه نیاز دارد، زیرا یک پیام اعلام مسیریاب که از چشم دور مانده باشد، ممکن است حل‌کننده‌ای را در اختیار دستگاه‌ها بگذارد که پیکربندی IPv4 را دور می‌زند.
حریم خصوصی با نسخه‌ای واحد برای همه بهتر نمی‌شود
سیاست آسان‌گیرانه‌تر خانه هوشمند، به‌طرزی عجیب کل شبکه را امن‌تر کرد
در نهایت، مهم‌ترین بهبود نه مسدود کردن دامنه‌های بیشتر، بلکه پذیرفتن این نکته بود که کنترل‌های حریم خصوصی باید با هر دستگاه سازگار شوند. DNS خانه هوشمندم عمداً سخت‌گیری کمتری دارد، اما اکنون کل شبکه خصوصی‌تر است؛ چون دیگر هر بار که یکی از لوازم از کار می‌افتد، سیاست اصلی را سست نمی‌کنم. هم‌زمان، نام‌های محلی سرویس‌ها جابه‌جایی، مستندسازی، دسترسی و تعمیر آنها را آسان‌تر کرده‌اند.
DNS ناگهان دستگاه‌های مشکوک را قابل‌اعتماد نمی‌کند، اما مرزهایی روشن‌تر، گزارشی متمرکز و محیطی مهارشده در اختیارتان می‌گذارد تا تعیین کنید هر دستگاه اجازه تفکیک چه نام‌هایی را دارد. همین تغییر کوچک در معماری سرانجام به پایداری و حریم خصوصی امکان می‌دهد در کنار هم باشند، نه اینکه یک‌درمیان یکدیگر را از کار بیندازند.
منبع: این مطلب ترجمه و بومی‌سازی مقاله‌ای از MakeUseOf به قلم Yadullah Abidi است. مشاهده مقاله اصلی