не использовать прокси сервер для адресов начинающихся с

не использовать прокси сервер для адресов начинающихся с

Когда прокси вредит: как исключить локальные адреса из туннеля

Не использовать прокси сервер для адресов начинающихся с

«не использовать прокси сервер для адресов начинающихся с» — это не просто настройка в браузере или системе. Это критически важное правило для тех, кто хочет сохранить доступ к собственной домашней сети, корпоративным ресурсам или IoT‑устройствам при активном VPN или прокси. Игнорирование этой опции приведёт к тому, что вы перестанете видеть свой роутер, NAS, принтер или умный холодильник. А если вы админ — потеряете управление всей инфраструктурой.

Почему ваш роутер «пропадает» при включённом VPN

Представьте: вы подключились к надёжному провайдеру типа Mullvad через WireGuard, запустили торрент и… больше не можете зайти в интерфейс роутера по 192.168.1.1. Причина проста: весь ваш трафик, включая обращения к локальным IP, ушёл в зашифрованный туннель. Сервер в Нидерландах не знает, где находится 192.168.1.1, и просто отбрасывает пакеты.

Это классическая проблема полного туннелирования (full tunnel). Решение — split tunneling (раздельное туннелирование) или настройка исключений (bypass rules). В Windows это делается через параметр «Не использовать прокси-сервер для адресов, начинающихся с», в macOS — через «Bypass proxy settings for these Hosts & Domains», а в Linux — через переменные окружения или iptables.

Но здесь кроется ловушка: многие пользователи просто добавляют 192.168.* и думают, что всё решено. На деле нужно учитывать все частные диапазоны IPv4, а иногда и IPv6.

Диапазоны, которые всегда должны быть в исключениях:

• 10.0.0.0/8 → всё, что начинается с 10.
• 172.16.0.0/12 → от 172.16.0.0 до 172.31.255.255
• 192.168.0.0/16 → все 192.168.x.x
• 127.0.0.0/8 → localhost и loopback
• ::1/128 → IPv6 localhost
• fc00::/7 → уникальные локальные адреса IPv6 (ULA)

Если вы пропустите хотя бы один — возможна частичная недоступность сервисов. Например, некоторые NAS-устройства Synology используют link-local IPv6 (fe80::/10) для обнаружения в сети.

Чего вам НЕ говорят в других гайдах

Большинство статей учат «просто поставить галочку». Но реальность сложнее.

1. Бесплатные VPN и прокси подменяют DNS, даже для локальных запросов
   Сервисы вроде Hola или Opera Free VPN внедряют свои DNS-резолверы глобально. Даже если вы исключили 192.168.1.1, ваш браузер может отправить запрос на my-nas.local через удалённый DNS, который вернёт NXDOMAIN. Результат — «сайт не найден», хотя устройство рядом.

2. Утечки через WebRTC игнорируют настройки прокси
   WebRTC использует STUN-запросы напрямую, минуя системный прокси. Если вы смотрите стриминг в Chrome с включённым VPN, но без блокировки WebRTC, ваш реальный IP может просочиться — даже если все адреса, начинающиеся с 10., исключены.

3. Kill switch может «отстрелить» локальный трафик
   Некоторые клиенты (особенно старые версии ProtonVPN) реализуют kill switch через жёсткие правила iptables/nftables. Они блокируют весь трафик при отвале соединения, включая локальный. Вы останетесь без интернета и без доступа к роутеру одновременно.

   🛡️Безопасный интернет

4. Корпоративные MDM-политики переопределяют ваши исключения
   Если вы работаете в компании с Intune или Jamf, администратор мог задать глобальный PAC-файл (Proxy Auto-Config), который игнорирует ваши локальные настройки. В этом случае «не использовать прокси сервер для адресов начинающихся с» просто не сработает — система будет следовать корпоративному скрипту.

5. Ложные «утечки» на тестовых сайтах
   Сервисы вроде ipleak.net показывают «DNS leak», если вы используете Cloudflare (1.1.1.1) или Google DNS (8.8.8.8). Но это не утечка — это осознанный выбор. Однако новички путают это с реальной проблемой и начинают отключать прокси полностью, теряя защиту.

Split tunneling: не только про IP, но и про домены

Настройка «не использовать прокси сервер для адресов начинающихся с» работает только с IP или простыми масками. Но современные сервисы — облачные и доменные. Например:

• *.corp.yourcompany.ru
• home.nas
• printer.local

Для таких случаев нужны продвинутые решения:

• OpenVPN с push route + exclude: через route-nopull и ручную настройку маршрутов.
• WireGuard с таблицами маршрутизации: создание отдельной таблицы для локального трафика.
• Роутеры с Policy-Based Routing (PBR): Keenetic, MikroTik, OpenWrt позволяют задавать правила по домену через dnsmasq + ipset.

Пример для OpenWrt:

Создаём ipset для локальных доменов
ipset create local-domains hash:ip
Добавляем разрешение для всех адресов из этого набора
iptables -t mangle -A PREROUTING -m set --match-set local-domains dst -j MARK --set-mark 0x2
Маркированный трафик идёт напрямую, минуя WG

Такой подход даёт контроль на уровне ядра, а не приложения.

Сравнение: как разные VPN-клиенты обрабатывают исключения

Важно: ExpressVPN и Surfshark намеренно отказались от split tunneling в базовых клиентах, ссылаясь на «максимальную безопасность». Но для локальных сетей это контрпродуктивно.

🛡️Безопасный интернет

Практические сценарии: когда исключения спасают

📡 Журналист в командировке
Подключается к общественному Wi-Fi в аэропорту Шереметьево. Включает VPN для защиты от снифферов. Но ему нужно синхронизировать заметки с локальным Obsidian на iPad через 192.168.43.10. Без исключений — синхронизация невозможна.

💻 Айтишник в кофейне
Работает из «Кофемании» на Тверской. Использует WireGuard для доступа к корпоративному GitLab. Но его SSH-агент должен взаимодействовать с YubiKey по USB-CDC, эмулирующему локальный IP. Исключение 169.254.0.0/16 (link-local) — обязательное условие.

📦 Владелец домашнего NAS
Загружает торренты через qBittorrent с включённым kill switch. Но хочет управлять загрузками через веб-интерфейс на 192.168.10.5. Если не указать исключение — интерфейс недоступен, даже при работающем интернете.

🚫 Обход блокировок мессенджеров
Пользователь в регионе с ограничениями подключает прокси для Telegram. Но его умная колонка Яндекса должна получать обновления с repo.yandex.ru (локальный CDN-кэш провайдера). Без исключения — колонка «зависает».

🔍 Утечка через WebRTC в Chrome
Даже при идеальном VPN, если не отключить WebRTC (chrome://flags/#disable-webrtc), сайт может получить ваш реальный IP через STUN. Это не связано с прокси-настройками, но часто маскируется под «проблему с исключениями».

Как правильно настроить исключения в разных ОС

Windows 10/11
1. Откройте «Параметры» → «Сеть и Интернет» → «Прокси».
2. Внизу — «Не использовать прокси-сервер для адресов, начинающихся с».
3. Введите:
10.*;172.16.*;172.17.*;172.18.*;172.19.*;172.20.*;172.21.*;172.22.*;172.23.*;172.24.*;172.25.*;172.26.*;172.27.*;172.28.*;172.29.*;172.30.*;172.31.*;192.168.*;127.*;localhost;*.local;*.corp
4. Перезапустите браузер.

Для PowerShell-проверки:
powershell Get-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings" -Name ProxyOverride

⚙️Технология доступа

macOS
1. Системные настройки → Сеть → Wi-Fi → Дополнительно → Прокси.
2. В поле «Исключения прокси-сервера» укажите:
*.local, 169.254/16, 192.168/16, 10/8, 172.16/12, localhost
3. Нажмите OK и примените.

Linux (GNOME)
Через gsettings:

gsettings set org.gnome.system.proxy ignore-hosts "['localhost', '127.0.0.1', '10.0.0.0/8', '172.16.0.0/12', '192.168.0.0/16', '*.local']"

Роутеры (Keenetic)
1. Веб-интерфейс → «Интернет» → «Прокси и VPN».
2. Включите «Исключить локальные адреса из туннеля».
3. Добавьте вручную IPv6-диапазоны, если используется.

Тестирование: убедитесь, что всё работает

1. Проверка доступа к роутеру:
   Откройте http://192.168.1.1 при включённом VPN. Должно загружаться мгновенно.

2. Проверка DNS:
   Используйте nslookup my-nas.local в терминале. Ответ должен приходить от локального DNS (часто роутер).

   🛡️Безопасный интернет

3. Проверка утечек:
   Зайдите на browserleaks.com/webrtc и ipleak.net. Убедитесь, что:

4. Ваш IP — от VPN
5. DNS — от провайдера или выбранного вами (не от провайдера VPN, если вы не хотели этого)

6. Нет «Local IP» в WebRTC, кроме локальных адресов

7. Тест скорости локальной сети:
   Передача файла между ПК и NAS должна идти на скорости выше 500 Мбит/с (при гигабитной сети). Если скорость падает до 10–20 Мбит/с — трафик уходит в туннель.

   🛡️Безопасный интернет

VPN замедляет интернет на сколько реально?

Зависит от протокола и расстояния до сервера. WireGuard добавляет 3–8 мс пинг и снижает скорость на 3–7% при хорошем канале. OpenVPN/UDP — 10–15 мс и 8–12% потерь. OpenVPN/TCP — до 30% из-за double ACK. Но локальный трафик (например, к NAS) не должен замедляться вообще — если он идёт через исключения.

Меня найдёт спецслужба при использовании VPN?

Если провайдер ведёт логи (даже «временные») и находится в юрисдикции 14 Eyes (включая США, Великобританию, Францию), по запросу суда он обязан передать данные. Поэтому выбирайте провайдеров с no-log policy, прошедших независимый аудит, и зарегистрированных вне 14 Eyes — например, в Швейцарии, Панаме или Швеции.

WireGuard или OpenVPN — что безопаснее?

Оба безопасны при правильной настройке. WireGuard использует современные криптопримитивы (Curve25519, ChaCha20, Poly1305) и меньше кода — меньше уязвимостей. OpenVPN проверен десятилетиями, но требует правильной конфигурации (TLS 1.3, AES-256-GCM). WireGuard не поддерживает perfect forward secrecy «из коробки», но компенсирует это частой сменой ключей (Rekey After Bytes).

Открой мир без границ🌍

Можно ли использовать бесплатный VPN для обхода блокировок?

Технически — да. Но бесплатно работают только те, кто монетизирует ваш трафик: встраивают рекламу, продают данные, используют ваше устройство как exit-ноду (как Hola). В 2023 году исследователи обнаружили, что 7 из 10 бесплатных VPN передавали историю посещений третьим лицам. Лучше заплатить 300–500 ₽/мес за проверенного провайдера.

Как отключить WebRTC в браузере?

В Chrome: зайдите в chrome://flags и включите «Disable WebRTC». В Firefox: about:config → media.peerconnection.enabled = false. В Edge — аналогично Chrome. Но учтите: это может сломать видеозвонки в некоторых сервисах (например, Jitsi).

Что делать, если после настройки исключений всё равно нет доступа к локальному серверу?

Проверьте три вещи: 1) Используется ли IPv6 — добавьте fc00::/7 и fe80::/10 в исключения. 2) Не блокирует ли брандмауэр входящие соединения на порт (например, 80 или 443). 3) Не включён ли «только туннель для приложений» в клиенте VPN — тогда системные настройки игнорируются. В таком случае настройте split tunneling внутри самого клиента.

Открой мир без границ🌍

Вывод

«не использовать прокси сервер для адресов начинающихся с» — это не техническая мелочь, а основа безопасной и функциональной работы в гибридной сети. Без этой настройки вы рискуете потерять контроль над собственными устройствами, даже имея «самый надёжный» VPN. Особенно в условиях, когда домашние сети становятся сложнее: умные лампочки, камеры, NAS, IoT-хабы — всё это живёт на частных IP и требует прямого доступа.

Правильно настроенные исключения — это баланс между приватностью и удобством. Они не ослабляют защиту, а делают её разумной. Помните: хороший VPN не прячет вас от всего мира, а защищает именно там, где есть реальная угроза — в публичных сетях, при работе с чувствительными данными, при обходе цензуры. А ваш роутер, NAS и принтер должны оставаться под рукой — без шифрования, без задержек, без лишних hops.

Проверьте свои настройки сегодня. Потому что завтра, в самый неподходящий момент, вы можете остаться без доступа к единственному месту, которое действительно ваше — своей локальной сети.