Вопрос или проблема
Я запустил ShadowSocks(Socks5)
tproxy и настроил iptable для маршрутизации всего трафика к нему. Он работает и принимает трафик, я могу получать доступ к веб-страницам, вводя IP-адрес; однако он не разрешает никакие запросы доменов/DNS. Я протестировал сеть следующими командами, которые, предположительно, подтверждают, что сеть работает, а проблема только с DNS. Обратите внимание, что все в порядке, если я просто использую обычный прокси ShadowSocks
. Я запустил tproxy с помощью следующей команды ss-redir -s ServerIP -p ServerPort -m EncryptionMethod -k MyPasswd -b 127.0.0.1 -l 60080 --no-delay -u -T -v
, и я использую Ubuntu 24.04 Noble на ядре gen 6+
$ nc -vz 172.217.163.46 80
Соединение с 172.217.163.46 80 порт [tcp/http] успешно!
$ nc -vz 172.217.163.46 443
Соединение с 172.217.163.46 443 порт [tcp/https] успешно!
$ nc -v -u 127.0.0.1 60080
Соединение с 127.0.0.1 60080 порт [udp/*] успешно!
$ nc -zvu 8.8.8.8 53
Соединение с 8.8.8.8 53 порт [udp/domain] успешно!
$ wget 172.217.163.46
--2024-11-06 18:05:45-- http://172.217.163.46/
Соединение с 172.217.163.46:80... подключено.
HTTP-запрос отправлен, ожидаем ответа... 301 Перемещено навсегда
Местоположение: http://www.google.com/ [следующее]
--2024-11-06 18:05:45-- http://www.google.com/
Разрешение www.google.com (www.google.com)... не удалось: Временная ошибка разрешения имени.
wget: не удалось разрешить хост-адрес 'www.google.com'
$ dig google.com @1.1.1.1
;; ошибка связи с 1.1.1.1#53: время вышло
Вот конфигурация ip tables
##################### SSREDIR #####################
iptables -t mangle -N SSREDIR
# connection-mark -> packet-mark
iptables -t mangle -A SSREDIR -j CONNMARK --restore-mark
iptables -t mangle -A SSREDIR -m mark --mark 0x2333 -j RETURN
# игнорировать трафик, отправленный на ss-server
iptables -t mangle -A SSREDIR -p tcp -d ServerIP --dport ServerPort -j RETURN
iptables -t mangle -A SSREDIR -p udp -d ServerIP --dport ServerPort -j RETURN
# игнорировать трафик, отправленный на зарезервированные адреса
iptables -t mangle -A SSREDIR -d 0.0.0.0/8 -j RETURN
iptables -t mangle -A SSREDIR -d 10.0.0.0/8 -j RETURN
iptables -t mangle -A SSREDIR -d 100.64.0.0/10 -j RETURN
iptables -t mangle -A SSREDIR -d 127.0.0.0/8 -j RETURN
iptables -t mangle -A SSREDIR -d 169.254.0.0/16 -j RETURN
iptables -t mangle -A SSREDIR -d 172.16.0.0/12 -j RETURN
iptables -t mangle -A SSREDIR -d 192.0.0.0/24 -j RETURN
iptables -t mangle -A SSREDIR -d 192.0.2.0/24 -j RETURN
iptables -t mangle -A SSREDIR -d 192.88.99.0/24 -j RETURN
iptables -t mangle -A SSREDIR -d 192.168.0.0/16 -j RETURN
iptables -t mangle -A SSREDIR -d 198.18.0.0/15 -j RETURN
iptables -t mangle -A SSREDIR -d 198.51.100.0/24 -j RETURN
iptables -t mangle -A SSREDIR -d 203.0.113.0/24 -j RETURN
iptables -t mangle -A SSREDIR -d 224.0.0.0/4 -j RETURN
iptables -t mangle -A SSREDIR -d 240.0.0.0/4 -j RETURN
iptables -t mangle -A SSREDIR -d 255.255.255.255/32 -j RETURN
# отметка первого пакета соединения
iptables -t mangle -A SSREDIR -p tcp --syn -j MARK --set-mark 0x2333
iptables -t mangle -A SSREDIR -p udp -m conntrack --ctstate NEW -j MARK --set-mark 0x2333
# packet-mark -> connection-mark
iptables -t mangle -A SSREDIR -j CONNMARK --save-mark
##################### OUTPUT #####################
# проксировать исходящий трафик с этого устройства
iptables -t mangle -A OUTPUT -p tcp -m addrtype --src-type LOCAL ! --dst-type LOCAL -j SSREDIR
iptables -t mangle -A OUTPUT -p udp -m addrtype --src-type LOCAL ! --dst-type LOCAL -j SSREDIR
##################### PREROUTING #####################
# проксировать трафик, проходящий через это устройство (другой->другой)
iptables -t mangle -A PREROUTING -p tcp -m addrtype ! --src-type LOCAL ! --dst-type LOCAL -j SSREDIR
iptables -t mangle -A PREROUTING -p udp -m addrtype ! --src-type LOCAL ! --dst-type LOCAL -j SSREDIR
# передать отмеченный пакет на TPROXY для обработки
iptables -t mangle -A PREROUTING -p tcp -m mark --mark 0x2333 -j TPROXY --on-ip 127.0.0.1 --on-port 60080
iptables -t mangle -A PREROUTING -p udp -m mark --mark 0x2333 -j TPROXY --on-ip 127.0.0.1 --on-port 60080
ip route add local default dev lo table 100
ip rule add fwmark 0x2333 table 100
ip rule del table 100 &>/dev/null
ip route flush table 100 &>/dev/null
Поскольку ни ShadowSocks, ни сервер не предоставляют DNS-сервис, как я уже говорил, вам, вероятно, придется настроить локальный DNS-пересыльщик, чтобы обрабатывать запросы DNS и маршрутировать их через ShadowSocks.
Я, вероятно, воспользуюсь dnsmasq
, потому что он прост и легковесен, и выполняет свою работу.
- Сначала установите его с помощью
apt
или любого другого менеджера пакетов, который вы используете. - Настройте dnsmasq:
- Настройте dnsmasq на использование предпочитаемых вами DNS-серверов (например, 1.1.1.1 или 8.8.8.8). Отредактируйте
/etc/dnsmasq.conf
:
server=1.1.1.1
server=8.8.8.8
- Установите dnsmasq для прослушивания на конкретном локальном IP и порту, например
127.0.0.1:5353
, добавив:
listen-address=127.0.0.1
port=5353
- Перенаправьте DNS-запросы на ShadowSocks:
- Обновите
/etc/resolv.conf
, чтобы указывать DNS-запросы на dnsmasq:
nameserver 127.0.0.1
- Измените свои правила iptables (что-то, чему я только недавно научился), чтобы перенаправить DNS-трафик (порт 53) на
127.0.0.1:60080
(TPorxy ShadowSocks):
iptables -t mangle -A PREROUTING -p udp --dport 53 -j TPROXY --on-ip 127.0.0.1 --on-port 60080
- Перезапустите dnsmasq и протестируйте его (может потребоваться
sudo
привилегии, имейте в виду):
systemctl restart dnsmasq
Ответ или решение
Проблема с разрешением DNS при активном прозрачном прокси на основе ShadowSocks
Ваша ситуация с прозрачным прокси, настроенным через ShadowSocks, и его об inability разрешать DNS-запросы, является распространенной проблемой среди пользователей, которые пытаются перенаправить трафик через программное обеспечение для обхода цензуры или повышения конфиденциальности. Давайте внимательно рассмотрим возможные шаги для решения этой проблемы.
1. Понимание проблемы
Вы упомянули, что напрямую используете IP-адреса для доступа к веб-страницам — это говорит о том, что сетевое подключение работает. Однако, когда дело касается DNS, ваши запросы не обрабатываются должным образом. Это может быть вызвано тем, что ShadowSocks не предоставляет службу DNS, а также возможной неправильной конфигурацией iptables.
2. Настройка локального DNS-переадресовщика
Для решения проблемы вам потребуется настроить локальный DNS-переадресовщик, чтобы он мог обрабатывать ваши DNS-запросы и отправлять их через ShadowSocks. Рекомендуем использовать dnsmasq
— легкий, но мощный инструмент для работы с DNS.
Шаги по настройке dnsmasq
:
-
Установите dnsmasq:
sudo apt install dnsmasq
-
Настройте dnsmasq:
Откройте файл конфигурации:sudo nano /etc/dnsmasq.conf
Включите следующие строки для указания DNS-серверов:
server=1.1.1.1 server=8.8.8.8
Задайте локальный IP и порт, на котором будет работать dnsmasq:
listen-address=127.0.0.1 port=5353
-
Обновите /etc/resolv.conf:
Убедитесь, что в файлеresolv.conf
прописан dnsmasq как ваш DNS-сервер:sudo nano /etc/resolv.conf
Добавьте строку:
nameserver 127.0.0.1
-
Настройте iptables для перенаправления DNS-запросов:
Добавьте правило для перенаправления трафика DNS через ваш прокси:sudo iptables -t mangle -A PREROUTING -p udp --dport 53 -j TPROXY --on-ip 127.0.0.1 --on-port 60080
-
Перезапустите dnsmasq:
После внесения всех изменений, перезапустите службу для применения конфигурации:sudo systemctl restart dnsmasq
3. Тестирование конфигурации
После настройки аналитики, проверьте, правильно ли работает DNS:
- Попробуйте снова выполнить команду
dig google.com @1.1.1.1
, чтобы убедиться, что DNS-запросы выполняются корректно. - Используйте команду
wget google.com
, чтобы проверить, решается ли доменное имя.
Заключение
Проблема с работой DNS при активном прозрачном прокси ShadowSocks может быть успешно решена с помощью настройки локального DNS-переадресовщика с помощью dnsmasq
. Это позволит обрабатывать ваши DNS-запросы и отправлять их через установленный вами прокси. Следуя приведенным выше шагам, вы сможете наладить корректное разрешение доменных имен, что позволит вам без затруднений использовать интернет.
Если проблемы сохраняются, рассмотрите возможность диагностики более глубоких сетевых или конфигурационных вопросов.