linux iptables использовать как прокси

linux iptables использовать как прокси

linux iptables использовать как прокси — правда и мифы

Подробный гайд: linux iptables использовать как прокси. Настройка, риски, утечки и альтернативы. Защити трафик без ложной безопасности.

linux iptables использовать как прокси — технически возможная, но часто неправильно понимаемая задача. Многие считают, что достаточно добавить пару правил в iptables, и весь трафик автоматически пойдёт через «прокси». На деле всё сложнее: iptables не создаёт прокси-соединение, он лишь перенаправляет пакеты. Без глубокого понимания сетевого стека Linux вы легко оставите уязвимости — от DNS-утечек до полного обхода вашего «туннеля» при сбое соединения.

Почему «прокси» через iptables — это не то, что вы думаете

iptables — это фреймворк фильтрации и модификации сетевых пакетов в ядре Linux. Он работает на уровне сетевого (L3) и транспортного (L4) слоёв модели OSI. А настоящий прокси (HTTP, SOCKS5) функционирует на прикладном уровне (L7). Это принципиальное различие.

Когда вы пишете:

iptables -t nat -A OUTPUT -p tcp --dport 80 -j DNAT --to-destination 10.0.0.1:3128

— вы не создаёте прокси. Вы просто подменяете адрес назначения для HTTP-трафика. Если на 10.0.0.1:3128 не запущен Squid или аналогичный HTTP-прокси, пакеты уйдут в никуда или вызовут ошибку соединения.

Разница между NAT и проксированием:

• NAT (Network Address Translation): меняет IP-адреса и порты в заголовках пакетов. Прозрачен для приложений.
• Прокси: принимает соединение от клиента, сам устанавливает новое соединение к серверу, пересылает данные. Приложение должно знать, что работает через прокси (или ОС должна его форсировать).

Однако iptables может имитировать поведение прокси в связке с полноценным VPN-туннелем. Например, вы направляете весь трафик в интерфейс wg0 (WireGuard), а iptables обеспечивает маскировку и предотвращает утечки. В этом случае «прокси» — это ваш удалённый сервер, а iptables — сторожевой пёс.

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

Большинство руководств в интернете обещают «анонимность за 5 минут». Они умалчивают о критических рисках:

1. DNS и WebRTC утекают даже при правильных правилах iptables
   Если вы не перехватываете DNS-запросы (udp/53, tcp/53, DoH, DoT), система будет использовать DNS провайдера. Ростелеком или МТС увидят, какие сайты вы посещаете, даже если сам трафик шифруется. WebRTC в браузерах раскрывает ваш реальный IP через STUN-запросы — iptables здесь бессилен без дополнительных мер.

2. Отсутствие kill switch = трафик в clear при обрыве
   Многие скрипты просто добавляют маршрут через туннель. Если WireGuard/OpenVPN падает, трафик автоматически возвращается на основной интерфейс. Никакого «автоматического отключения». Настоящий kill switch требует блокировки всего OUTPUT-трафика, кроме туннеля, через iptables.

3. Провайдеры видят метаданные
   Даже при идеальном NAT провайдер знает: объём трафика, время подключения, порты, частоту запросов. В России с 2023 года все операторы обязаны хранить метаданные до 3 лет. Это достаточно для профилирования.

   📖Свобода информации

4. Юрисдикция важна не для iptables, а для сервера
   iptables работает локально. Но если вы перенаправляете трафик на VPS в США, Германии или Нидерландах — вы подпадаете под их законы. Страны «14 Eyes» могут потребовать логи у хостинг-провайдера. Бесплатные «прокси-сервисы» часто размещены именно там.

5. Ядро Linux само логирует подключения
   Подсистема nf_conntrack отслеживает все соединения. По умолчанию она хранит записи в памяти. При аварийном отключении эти данные могут остаться на диске (например, в swap). Для высокой конфиденциальности нужно отключать conntrack или использовать --notrack.

Когда iptables действительно помогает в схеме с VPN

iptables становится мощным инструментом в связке с VPN. Вот где он незаменим:

Split tunneling по UID
Вы хотите, чтобы только торрент-клиент ходил через VPN, а остальное — напрямую? Маркируйте пакеты по UID пользователя:

Создаём таблицу маршрутизации
echo "200 vpn" >> /etc/iproute2/rt_tables

Маркируем трафик от пользователя 'qbittorrent'
iptables -t mangle -A OUTPUT -m owner --uid-owner $(id -u qbittorrent) -j MARK --set-mark 100

Направляем маркированный трафик в отдельную таблицу
ip rule add fwmark 100 table vpn

В таблице vpn — маршрут через туннель
ip route add default dev wg0 table vpn

True kill switch на уровне netfilter
Блокируем весь исходящий трафик, кроме туннеля и локальной сети:

Разрешаем loopback и локальную сеть
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 192.168.0.0/16 -j ACCEPT

Разрешаем трафик через туннель (например, wg0)
iptables -A OUTPUT -o wg0 -j ACCEPT

Всё остальное — DROP
iptables -A OUTPUT -j DROP

Теперь при падении wg0 интернет полностью отключится — никаких утечек.

Интеграция с WireGuard
Используйте PostUp и PreDown в конфигурации .conf:

[Interface]
PrivateKey = ...
Address = 10.8.0.2/24
PostUp = iptables -A OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -j REJECT

Это автоматизирует kill switch при подъёме/опускании интерфейса.

Сравнение: настоящий прокси vs iptables-перенаправление

Примечание: «Минимален» означает, что утечки возможны только при ошибке конфигурации. WireGuard и OpenVPN из коробки шифруют весь трафик, включая DNS, если правильно настроены.

Пошаговая настройка: безопасное перенаправление через iptables

Предположим, у вас есть VPS с WireGuard. Цель — направить весь трафик через него с защитой от утечек.

Шаг 1. Проверка поддержки netfilter
Убедитесь, что модули загружены:

lsmod | grep nf_nat
Должно быть: nf_nat, nf_conntrack и др.

Шаг 2. Маркировка трафика (опционально для split tunneling)
Если нужен split — см. пример выше по UID.

Шаг 3. Создание таблицы маршрутизации

echo "200 tunnel" >> /etc/iproute2/rt_tables
ip route add default dev wg0 table tunnel
ip rule add not fwmark 0x100 table tunnel  # если используете маркировку

Шаг 4. Правила iptables для маскировки и блокировки

SNAT для исходящих пакетов
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE

Kill switch
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 10.0.0.0/8 -j ACCEPT   # локальные подсети
iptables -A OUTPUT -o wg0 -j ACCEPT
iptables -A OUTPUT -j DROP

Шаг 5. Тестирование
- Запустите tcpdump -i any host ipleak.net — должен показывать трафик только через wg0.
- Откройте ipleak.net — проверьте IP, DNS, WebRTC.
- Имитируйте обрыв: sudo wg-quick down wg0. Интернет должен полностью пропасть.

Реальные сценарии использования в RU-регионе

Айтишник в кофейне
В публичном Wi-Fi соседи могут сниффить трафик. Через iptables + WireGuard весь трафик шифруется. Провайдер кофейни видит только зашифрованное соединение к одному IP.

Журналист: обход блокировки Telegram
Telegram периодически блокируют в РФ через DPI. Самостоятельный WireGuard-сервер + iptables маскирует трафик под обычный HTTPS (порт 443). Ростелеком не может отличить его от трафика к Google.

Пользователь торрентов
Изолируйте только торрент-клиент через UID-маркировку. Остальной трафик (банки, почта) идёт напрямую — быстрее и безопаснее. При этом раздачи идут через зарубежный IP.

Корпоративная сеть
Администратор принудительно направляет трафик сотрудников в корпоративный шлюз через iptables на роутере OpenWrt. Все соединения логируются и фильтруются централизованно.

Обход DPI Ростелекома
Комбинируйте WireGuard на нестандартном порту (например, 443/TCP) с правилами iptables, которые фрагментируют пакеты или добавляют padding. Это усложняет анализ трафика системами глубокой инспекции.

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

Зависит от протокола и сервера. WireGuard добавляет 5–15 мс пинга и сохраняет 90–98% скорости канала. OpenVPN — 15–40 мс и 70–90%. На 100 Мбит/с вы получите 70–98 Мбит/с. Бесплатные VPN часто дают меньше 10 Мбит/с из-за перегрузки.

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

Если вы используете коммерческий VPN с no-log policy и аудитом — маловероятно. Но если сервер ваш (VPS), то IP известен хостинг-провайдеру. В РФ по запросу ФСБ они обязаны предоставить данные владельца. Анонимность требует оплаты криптой и использования Tor для регистрации.

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

Оба используют современное шифрование (AES-256-GCM или ChaCha20). WireGuard проще, быстрее и имеет меньше кода — значит, меньше уязвимостей. OpenVPN поддерживает больше опций (TLS-auth, comp-lzo), но сложнее настраивать. Для большинства пользователей WireGuard предпочтительнее.

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

Можно ли полностью отключить логирование в Linux при использовании iptables?

Частично. Отключите journald для сетевых событий, очистите dmesg, отключите nf_conntrack для трафика через NOTRACK. Но некоторые данные (время подключения, объём) остаются в ядре. Для максимальной чистоты используйте live-дистрибутивы (Tails).

Бесплатный VPN через iptables — это реально?

Нет. Если вы перенаправляете трафик на бесплатный «прокси» — это ловушка. Такие сервисы собирают ваши данные, подменяют рекламу или используют ваш канал как выходной узел (как Hola). Настоящий прокси или VPN требует аренды сервера — от $3–5/мес. Бесплатного сыра не бывает.

Как проверить, не утекает ли трафик при сбое VPN?

1. Запустите ping 8.8.8.8.
2. Отключите VPN вручную.
3. Если пинг продолжается — утечка есть.
Используйте tcpdump -i eth0 для мониторинга трафика на основном интерфейсе. Идеальный kill switch покажет ноль пакетов.

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

Вывод

linux iptables использовать как прокси — технически корректно только в контексте перенаправления трафика в полноценный туннель (VPN). Сам по себе iptables не обеспечивает шифрования, анонимности или обхода блокировок. Его сила — в контроле: он может гарантировать, что ни один байт не уйдёт мимо вашего защищённого канала. Но без правильно настроенного WireGuard/OpenVPN, без тестирования на утечки и без понимания юрисдикции сервера вы получите ложное чувство безопасности. В условиях российской цензуры и DPI это особенно опасно. Используйте iptables как щит, а не как меч.