sbh: Да, задача интересная, но у меня нет точного ответа на Ваш вопрос. Трафик от локального приложения можно полностью заблокировать, но я не нашел вариантов, чтобы можно было указать какие-то исключения.
Нужно в Правила для исходящих соединений (см. Панель управления\Система и безопасность\Администрирование\Брандмауэр Windows в режиме повышенной безопасности) добавить новое блокирующее правило для программы. Тогда данная програма не будет работать с сетью.
Можно еще попробовать установить настройки по умолчанию для блокировки всего исходящего трафика и для приложения сделать разрешающее правило с указанием адресов локальной сети, но такой вариант осложнен тем, что нужны явные разрешающие правила и для остальных программ.
Спросите про исключения в Правилах исходящего трафика на брандмауэрах виндовс у профильных специалистов, может есть какой-то вариант.
SysUtils: даже если и забыл (так оно и есть), то не сложно вспомнить по сообщениям выше.
Из пояснения ничего не ясно. Покажите вывод команд на роутере, где стоит Redsocks:
ip a
ip r s
iptables-save
sysctl net.ipv4.ip_forward
И конфиг Redsocks покажите.
Без редсокса работает пересылка трафика лан-ви-фи в интернет?
Про редсокс в качестве роутера я писал выше:
Note, you should have proper `local_ip' value to get external packets with
# redsocks, default 127.0.0.1 will not go. See iptables(8) manpage regarding
# REDIRECT target for details.
# Depending on your network configuration iptables conf. may be as easy as:
root# iptables -t nat -A PREROUTING --in-interface eth_int -p tcp -j REDSOCKS
Денис: с точки зрения программы, это запрос на запуск. В меню отправить есть и Я.Диск, вот он и стартует, раз не был еще запущен. Тут либо забить на это, либо старательно вычищаеть в реестре подобные записи, чтобы он запускался только по клику по ярлыку и нигде больше не был прописан. Где эти ключи, я не знаю, но в интернете точно можно найти настройки меню "Отправить", а уже там и Я.Диск искать.
Mr_Howell: речь про статический маршрут в сеть 2000::/3?
В этом точно не уверен, но в /etc/network/interfaces либо в секции auto he-ipv6, либо ниже используя добавить через up или port-up: ip -6 route add 2000::/3 dev he-ipv6
Перезапустить
sudo service networking restart
и проверить маршруты
sudo ip r s
Руками ничего не нужно запускать после рестарта сервера, ищите причину, почему не работает.
Mr_Howell: ошибка в начале, при проверке, это из-за того, что Вы не назначили адрес на интерфейс.
Закрепить статический маршрут и дополнительные адреса можно добавив строчку в файл /etc/network/interfaces в секцию про he-ipv6 (вроде так, уточните в интернете, если не сработает):
up ip -6 route add 2000::/3 dev he-ipv6
up ip -6 a a 2001:470:1f0b:b7f::11/64 dev he-ipv6 noprefixroute
Либо, если надо много адресов на интерфейсе, пользуйтесь скриптами и директивой post-up /path/to/script.sh.
В комментах был вопрос про 3proxy. Если еще актуально могу подсказать, задавайте только отдельный вопрос,т.к. в комментах не ясна Ваша проблема.
netfilter-persistent is a loader for netfilter configuration using a plugin-based architecture.
iptables-save > /etc/iptables/rules.v4
Вы путаете назначение iptables и NAT.
Если будет прокси, то NAT не нужен - все запросы в сеть через прокси. Если надо заблокировать доступ из вне к шлюзу или локалке - iptables, но без NAT.
SysUtils: Пожалуйста! Вынес итоговый ответ из комментариев, возможно кому-то еще пригодится, что-бы не читать наше с Вами обсуждение.
С WebRTC не работал, но думаю это обычный прикладной протокол, возможно поверх HTTP/S, и транспорт там точно TCP, поэтому соксификация трафика не должна отличаться от той. что Вы пытаетесь сделать с Redsocks. Если нужны какие-то дополнения, то лучше вынести это в отдельный конкретный вопрос (возможно несколько) с подробным описанием задачи.
SysUtils:
Не знаю, почему bind не переключается на запросы по tcp, если заблокированы udp, наверное надо задать конкретный вопрос на профильном форуме.
Проверил с dnsmasq. Заблокировал исходящие 53/udp и работал он только, если явно отправлять запросы по tcp:
iptables -A OUTPUT -o eth0 -p udp -m udp --dport 53 -j REJECT
dig 127.0.0.1 ya.ru +tcp
Получается, что вышеперечисленные правила редиректа или блокировки верны и они свое дело делают, но почему bind или клиент не переключаются при этом на tcp-запросы - это для меня загадка.
SysUtils:
Все все путаете и смешиваете, поэтому ничего не получается. Может и сервис не поднят, Вы проверяли?
Bind используется и взамен, и вместе с dnstc, DNS Socks Proxy вместо Bind. Используете одно, выключите все остальное.
Про Bind. Если Вы запретите исходящий upd трафик (хотя-бы для dport=53/udp), то вероятно он начнет использовать 53/tcp для отправки запросов. А уже этот трафик будет проксироваться Redsocks как и весь остальной трафик, тут дополнительных правил не нужно. Только заставить работать Bind по TCP, либо настройками либо ломом.
Про dnstc + Bind. Можно обрывать оправку запросов от bind'a и dnstc. Навероное достаточно такого правила:
iptables -t nat -A OUTPUT -p udp --dport 53 -j REDIRECT --to-ports 5300
Про DNS Socks Proxy. Выключаете Bind и редирект, запускаете утилиту, она слушает локальный 53/udp и проксирует на socks сервер принятые запросы и только. Сразу и без обрыва udp.
В любом случае днс-запросы должны идти на 127.0.0.1:53, а не куда-либо еще, что бы локальные процессы за разрешением имен шли к DNS Socks Proxy, а не внешний ДНС-сервер. Понимаете? Проверяйте nslookup yandex.ru 127.0.0.1
SysUtils:
Cудя по описанию, DNS SOCKS Proxy отлично подходит для Вашей задачи. Он делает ровно тоже самое, что и Редсокс, только для днс-запросов, а не всего трафика. Он слушает порт на интерфейсе и все входящие запросы проксирует (перенаправляет) через сокс-сервер и дальше. Только обратите внимание, что DNS SOCKS Proxy только проксирует запросы _через_ прокси-сервер, он не направляет запросы к определенному ДНС-серверу, эти Вы должны отдельно настроить.
Ну и что-бы трафик не шел наружу, просто заблокируйте все исходящие соединения (но это только после отладки работы проксирования):
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d SOCKSIP -j ACCEPT
iptables -P OUTPUT DROP
В логах есть что-то?
journalctl -b -r
journalctl -u iptables.service
И похоже, что в правилах используется какой-то модуль, которого нет в текущем ядре. Посмотрите дамп iptables, правила с ключом -m. Проверьте загружены модули в ядро lsmod или попробуйте загрузить modprobe.
SysUtils: Вы посмотрели DNS SOCKS Proxy или DNSChef (у него даже специальная опция есть, чтобы сразу делать запросы по tcp: DNSChef implements a TCP mode which can be activated with the --tcp flag)? Чем они не устраивают, и без костылей для Редсокса.
SysUtils:
> Конечная цель, это полностью фильтрация трафика через Socks.
Что Вы понимаете под "фильтрация"? SOСKS - это протокол проксирования, или речь может идти о SOCKS proxy-сервере. Т.е. Вы хотите весь внешний трафик отправлять на socks-сервер, чтобы он его уже дальше пускал в сеть от своего имени/адреса. Так?
Какой смысл отправлять на SOCKS-сервер dns-запросы? Почему не хотите пользоваться публичными днс-серверами?
С днс-запросами я вижу два варианта: 1. запретить локальным процессам выходить в сеть напрямую; 2. параноидальный режим, пробрасывать весь трафик до SOCKS-сервера. В вар. 1 нужен только кешируюший ДНС-сервер, который сам будет ходить в сеть, а не локальные процессы или хосты (dnsmasq, bind9). Вар. 2 надо чтобы днс-запросы ходили не по udp-протоколу, а по tcp.
Учтите, что днс-запросы идут по сети в открытом виде, только если канал до socks-сервера у Вас не шифруется, только тогда есть какой-то смысл в таких действиях.
Автор правильно пишет, нужно чтобы исходящие запросы в сеть были по tcp-протоколу. Настраивали так bind9? Если он реально ходит за разрешением имен по tcp, то и дополнительных настроек не нужно будет, если Вы пишите, что остальной трафик проксируется правильно. ДНС-сервер с запросами по tcp, ничем не отличается от браузера на сетевом уровне.
Проверяйте настройки bind9, удалите лишние правила iptables, что Вы писали в первом сообщении и все должно работать. Проверить отправку запросов по tcp можно так: tcpdump -i eth0 port 53.
Зачем Вам редирект если есть кеширующий bind? Кажется там нужно не sport ставить, а --dport, для правильного редиректа. Просто не знаю, как и зачем работает dnstc. Но предполагаю, что Вы пытаетесь перенаправить исходящие по upd днс-запросы.
Что Вы хотите в итоге реализовать?
Если нужно запретить любой трафик из локальной сети, то смотрите dnsmasq.
Хотите подменить "на лету" адрес ДНС-сервера? Тогда либо dnschef, либо пробовать DNAT iptables.
Хотите подменять определенные ответы от ДНС-сервера?
Вы все это делаете на одном хосте локально или есть шлюз с редсокс и есть клиент, которому надо подменить адрес ДНС?
Нужно в Правила для исходящих соединений (см. Панель управления\Система и безопасность\Администрирование\Брандмауэр Windows в режиме повышенной безопасности) добавить новое блокирующее правило для программы. Тогда данная програма не будет работать с сетью.
Можно еще попробовать установить настройки по умолчанию для блокировки всего исходящего трафика и для приложения сделать разрешающее правило с указанием адресов локальной сети, но такой вариант осложнен тем, что нужны явные разрешающие правила и для остальных программ.
Спросите про исключения в Правилах исходящего трафика на брандмауэрах виндовс у профильных специалистов, может есть какой-то вариант.