Файл 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 зноў зрушыць шлях.