Файл hosts проти фільтра на маршрутизаторі: блокування сайту через VPN

Запис у файлі hosts і фільтр на маршрутизаторі блокують той самий сайт із цілком різних причин, тому один продовжує працювати під VPN, а інший тихо припиняє. Файл hosts відповідає на ім'я раніше, ніж хоч один пакет залишить машину. Фільтр на маршрутизаторі переглядає трафік, що проходить через нього. Поставте тунель між цими двома точками, і другий втрачає огляд, а перший нічого не помічає.

Де вирішується ім'я, вирішує все

Кожне блокування починається з питання: хто перетворює ім'я на адресу? На звичайному настільному комп'ютері відповідає системний резолвер, який іде за заданим порядком і зазвичай читає файл hosts раніше, ніж звертається до DNS. У фільтрованій мережі відповідь може дати маршрутизатор, який бачить запит лише тоді, коли клієнт надсилає його через нього без захисту. Змініть шлях — зміните, кому дозволено відповідати.

VPN робить тут дві речі одразу: він зсуває маршрут за замовчуванням і може нав'язати свій DNS-сервер. Будь-якої з цих змін достатньо, щоб відвести розв'язання імен від пристрою, який застосовував блокування.

Це механізм знайомої скарги: фільтр працює, доки не підключиться VPN.

Запис hosts відповідає раніше, ніж існує тунель

Рядок на кшталт 127.0.0.1 www.example.com читає локальний резолвер, тому відповідь створюється на машині без участі мережі. Підключіть тунель, змініть DNS-сервер, змініть мережу: запис усе одно повертає loopback. Тому блокування через hosts — єдине з двох, на яке не впливає місце завершення VPN.

Його сліпі зони так само локальні. Застосунок, який несе свій резолвер, говорить DNS over HTTPS або підключається до буквальної адреси, ніколи не питає систему, тому запис не використовується. Адреса в кеші працюючого процесу дає той самий ефект, доки цей процес не перезапуститься.

Підтвердьте відповідь за допомогою getent ahosts у Linux або Resolve-DnsName у Windows, а не довіряючи вкладці браузера.

Фільтр на маршрутизаторі бачить лише те, що через нього проходить

Фільтр вмісту або URL на домашньому маршрутизаторі зіставляє імена та запити, які проходять через нього в читабельній формі. Коли клієнт будує шифрований тунель до сервера деінде, маршрутизатор бачить один потік до цього сервера і нічого всередині. Фільтру немає з чим зіставляти ім'я, тому він пропускає трафік, і це виглядає як відмова фільтра, а не як обхід.

Працює інша топологія: маршрутизатор сам тримає тунель, розшифровує на кінці й застосовує фільтр там. У такій схемі фільтр стоїть там, де з'являється відкритий текст.

Якщо тунель закінчується на ноутбуці, маршрутизатор за визначенням перебуває поза захищеним шляхом, хоч би як було записано правило.

Чотири точки застосування і що кожна пропускає

Чотири місця можуть застосувати блокування, і кожне відмовляє по-своєму. Читайте список як карту покриття, а не як рейтинг.

• Файл hosts або локальний резолвер: працює офлайн і під будь-яким тунелем, але його обходить вбудований резолвер або жорстко задана адреса.
• Фільтрація DNS на шлюзі VPN: охоплює клієнтів, які використовують нав'язаний резолвер, і пропускає клієнтів, які обходять DNS.
• Правила виходу на шлюзі за адресою або SNI: незалежні від DNS клієнта, але сліпі до імен, які не можуть прочитати, і до адрес, яких не вивчили.
• Керована політика браузера або пристрою: сильна на керованому обладнанні, відсутня на особистих пристроях.

Жодне з цього не є межею безпеки проти цілеспрямованого користувача на некерованому пристрої. Це засоби політики, і чесний опис каже, який трафік кожен із них насправді покриває.

Виберіть шар, що відповідає наміру: домашня зручність належить пристрою, а організаційне правило — шлюзу.

Перевірте обидва стани, перш ніж назвати це завершеним

Запустіть ті самі три команди з підключеним і вимкненим VPN: getent ahosts, щоб побачити відповідь резолвера, nslookup, щоб побачити, що повертає запит, і curl -I до сайту, щоб побачити, чи ще завершується з'єднання. Якщо перша повертає loopback, а третя підключається до справжньої адреси, щось обійшло резолвер, і запис hosts не той контроль, про який ви думаєте.

На маршрутизаторі прочитайте лічильники фільтра до запиту і після. Лічильник, який ніколи не рухається, означає, що трафік так і не дійшов до фільтра, і це відповідь маршрутизації, а не правила.

Запишіть результат разом із топологією, бо наступна зміна VPN знову зсуне шлях.