LINUX.ORG.RU
ФорумAdmin

3proxy с несколькими внешними интерфейсами. Работает только какой-либо один.

 ,


0

1

Здравствуте.

Для проксирования в сети выделена машина с Debian 9. Прокси-сервер - 3proxy.
Интерфейсы:
enp3s0 - локалка, вход прокси
enp0s29f7u1, enp0s29f7u3 - 4G-модемы, выходы прокси (пока в тесте 2, потом будет больше). DHCP на модемах отключен.
virbr0 - default network от QEMU/KVM - болтается на машине, никому не мешает (вроде).

Интерфейсы кроме virbr0 подняты через /etc/network/interfaces:

auto lo
iface lo inet loopback

allow-hotplug enp3s0 # это локалка
auto enp3s0
        iface enp3s0 inet static
                address 192.168.200.100
                netmask 255.255.255.0
                gateway 192.168.200.1
                dns-nameservers 192.168.200.1 8.8.8.8

allow-hotplug enp0s29f7u1 # это модем 1
auto enp0s29f7u1
        iface enp0s29f7u1 inet static
                address 192.168.110.100
                netmask 255.255.255.0
                gateway 192.168.110.1
                dns-nameservers 192.168.110.1 8.8.8.8

allow-hotplug enp0s29f7u3 # это модем 2
auto enp0s29f7u3
        iface enp0s29f7u3 inet static
                address 192.168.111.100
                netmask 255.255.255.0
                gateway 192.168.111.1
                dns-nameservers 192.168.111.1 8.8.8.8

Конфиг 3proxy (/etc/3proxy/3proxy.cfg):

daemon
auth strong

nserver 8.8.8.8
nserver 8.8.4.4

nscache 65536

timeouts 1 5 30 60 180 1800 15 60

internal 192.168.200.100

users qwerty:CL:123456

log /var/log/3proxy/3proxy.log
logformat "- +_L%t.%. %N.%p %E %U %C:%c %R:%r %O %I %h %T"
archiver gz /usr/bin/gzip %F
rotate 1

# что делает этот блок не очень понимаю, взял из дефолтного конфига 3proxy уже когда искал причину описанной ниже ошибки. Поэтому думаю он не влияет
authcache user 60
auth strong cache
deny * * 127.0.0.1,192.168.200.100
allow * * * 80-88,8080-8088 HTTP
allow * * * 443,8443 HTTPS

auth strong cache
flush
proxy -n -a -p8810 -e192.168.110.100
proxy -n -a -p8811 -e192.168.111.100

auth iponly strong
flush
socks -n -a -p8310 -e192.168.110.100
socks -n -a -p8311 -e192.168.111.100

auth strong cache
flush
admin -p2525

Метрики интерфейсам по умолчанию не назначены:

# route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.110.1    0.0.0.0         UG    0      0        0 enp0s29f7u1
192.168.110.0    0.0.0.0         255.255.255.0   U     0      0        0 enp0s29f7u1
192.168.111.0    0.0.0.0         255.255.255.0   U     0      0        0 enp0s29f7u3
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0
192.168.200.0   0.0.0.0         255.255.255.0   U     0      0        0 enp3s0

Проблема заключается в том, что проксируемый трафик ходит только через интерфейс, на котором поднимается дефолтный gateway (в выводе nroute выше - 192.168.110.0).
Т.е. http прокси qwerty:12345@192.168.200.100:8810 и socks 192.168.200.100:8310 работают, а 192.168.200.100:8811 и 192.168.200.100:8311 - нет.
Если назначить метрики и сделать приоритет 192.168.111.100 выше (соответственно дефолтным становится gateway 192.168.111.1), то наоборот: 192.168.200:8811 и 192.168.200:8311 работают, а 192.168.200:8811 и 192.168.200:8311 - нет.
Работу прокси проверяю в Firefox на другой машине в сети.

Включение/отключение IP Forwarding в /etc/sysctl.conf:

net.ipv4.ip_forward=1
не помогает (оставил включенным).

Пробовал оставить только http-прокси или только socks - все равно.

В iptables ничего не назначено:

# iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:bootps

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             192.168.122.0/24     ctstate RELATED,ESTABLISHED
ACCEPT     all  --  192.168.122.0/24     anywhere            
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootpc

В чем может быть дело, сам уже теряюсь в догадках?



Последнее исправление: neuro75 (всего исправлений: 4)

Так у тебя маршрут по умолчанию один, логично что оно не будет работать.

Тут явно напрашивается policy based routing

Pinkbyte ★★★★★
()
Ответ на: комментарий от Pinkbyte

Ну да. Тут я уткнулся в недопонимание основ сетей.

Есть прокси-сервер у которого прописан входной интерфейс и выходные, переход на которые должен происходить основываясь на порте на который пришло обращение. С моей обывательской точки зрения этот «черный ящик» и должен маршрутизацию разруливать в зависимости от того, что на него пришло. Но получается, что не разруливает, если пришло на дефолтный gateway, то все хорошо, а если на не-gateway - то все плохо.

Также есть правила routing’a на основе политик. Т.е. iproute2+iptables. Не очень понятно пока, как они работают, но сижу разбираюсь. Главное понятен принцип - нужно создать отдельные таблицы маршрутизации (или роутинга? или это одно и тоже?) для каждого выходного интерфейса.

Так вот, в голове не очень укладывается, как эти два предыдущих посыла между собой связаны? И именно этого понимания и не хватает чтобы уложить 2+2 и все настроить.

Если настроить роутинг на основе политик, то какова вообще роль прокси-сервера, если все и так будет разруливаться политиками?

Будет ли прокси продолжать выполнять роль анонимайзера при такой схеме? Т.е. он как-то сам по себе встроится в прописанный маршрут? Он вообще будет как-то участвовать?

Вот на этих вопросах застрял.

neuro75
() автор топика
Ответ на: комментарий от neuro75

Так вот, в голове не очень укладывается, как эти два предыдущих посыла между собой связаны? И именно этого понимания и не хватает чтобы уложить 2+2 и все настроить.

Не могу сказать насчет 3proxy, я такое на нем не делал и не знаю вообще возможно ли это, но в том же squid логика такая - можно указать выходной ip-адрес, с которого будет отправлен запрос наружу. Например сделать acl для группы логинов/ip-адресов клиентов и направить трафик от них через один адрес, а для всех остальных - через другой.

А вот к этому адресу источника уже привязывается политика, указывающая шлюз по умолчанию - и соответственно интерфейс через который трафик пойдет наружу.

Соответственно ответные пакеты для трафика приходящего на сервер - абсолютно также попадает под политику и маршрутизируются как надо.

Если настроить роутинг на основе политик, то какова вообще роль прокси-сервера, если все и так будет разруливаться политиками?

А кто определит каких клиентов через какой адрес выпускать - например если клиенты определяются по логину, а не по IP-адресу с которого они шлют запросы? И как вообще определять их по логину, то есть авторизовывать? Нет, если тебе ВООБЩЕ в принципе не нужен прокси сервер и достаточно сопоставлять клиентов по их IP-адресам, тогда да - можно обойтись просто маршрутизацией.

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 3)
Ответ на: комментарий от Pinkbyte

А кто определит каких клиентов через какой адрес выпускать - например если клиенты определяются по логину, а не по IP-адресу с которого они шлют запросы? И как вообще определять их по логину, то есть авторизовывать? Нет, если тебе ВООБЩЕ в принципе не нужен прокси сервер и достаточно сопоставлять клиентов по их IP-адресам, тогда да - можно обойтись просто маршрутизацией.

Мне нужны задачи: 1. Перенаправление трафика на разные внешние интерфейсы в зависимости от того, на какой порт внутреннего интерфейса он пришел. Логин\пароль вообще не нужны (трафик же из локалки) и рассматриваются как паразитарная сущность, с которой надо мириться. 2. Анонимизация трафика в части: не светить снаружи внутренний IP, ОС, DNS локальной машины, обратившейся к прокси-машине (вообще каким-либо образом не показывать что используется перенаправление, источником трафика, видимым снаружи, сделать прокси-машину).

С первой задачей 3proxy справился частично (1 интерфейс же работает :-) ). Со второй не справился вообще, несмотря на то, что собран из исходников со вставкой #define ANONIMOUS 1 (по памяти пишу, но как-то так). Точнее - всякие whoer и т.д. говорят - признаков использования прокси не найдено (молодец, себя не светит), но одновременно показывают в поле «ваш IP» - IP модема, а в полях «локальный IP», «OS», «DNS» - параметры локальной машины от которой исходит трафик. Т.е. анонимность как таковая отсутствует. Этот вопрос я отложил на потом, но сомневаюсь, что она методами 3proxy решаема. Во всяком случае, перечитав тонну мануалов я вроде все для ее решения сделал.

Таким образом, возникает резонный вопрос: можно ли эти две задачи решить руками (только методами iproute2 или еще каким дополнительным низкоуровневым ПО для правки заголовков проходящих пакетов)?.

При этом, если даже если можно решить только первую, но в полном объеме, от прокси можно все равно отказаться: один черт ничего не анонимирует, кроме самого себя.

anonymous
()
Ответ на: комментарий от anonymous

Мне нужны задачи: ...
Таким образом, возникает резонный вопрос: можно ли эти две задачи решить руками (только методами iproute2 или еще каким дополнительным низкоуровневым ПО для правки заголовков проходящих пакетов)?.

Для указанных тобой задач в полном объеме всё решается через iproute2 + iptables. Прокси тебе вообще не нужен

Pinkbyte ★★★★★
()
Последнее исправление: Pinkbyte (всего исправлений: 2)
Ответ на: комментарий от anonymous

Мимо крокодил. Дополню ответ выше:

«локальный IP», «OS», «DNS» - параметры локальной машины от которой исходит трафик.

В вашем случае это все отдает ваш браузер. Можно ли как-то кроить ответы от браузеров на уровне прокси, не знаю, не заморачивался. Теоретически наверное возможно, но вот реальные варианты...
В части DNS тут думаю простая проверка в виде DNS leak. Вот это решаемо, но сильно зависит от задачи в целом. Например у вас какой-нибудь адский АД с кучей АД, и т.д. надо рассматривать всю инфраструктуру. Или банальщина в виде домашней локалки, это другое.

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.