LINUX.ORG.RU
Ответ на: комментарий от ventilator

В общем, задача немного изменилась и все на данный момент выглядит так

Есть сервер для обработки данных и он в интернете. К нему есть некторое количество прокси-серверов, которые проксируют http-запросы на определенные порты этого сервера. Т.е. схема такова:

user -> proxy1:80 -> server:2220 

user -> proxy2:80 -> server:2221
И так далее для всех прокси. Но на сервере необходимо фиксировать ip всех клиентов. Вот данные

Server: (IP самого сервера - yyy.162.190.160 )
root@server:/# ip ro sh
xxx.20.117.1 dev eth0  scope link 
yyy.162.190.0/24 dev eth0  proto kernel  scope link  src yyy.162.190.160 
yyy.162.0.0/16 dev eth0  proto kernel  scope link  src yyy.162.142.136 
default via yyy.162.182.110 dev eth0 
root@server:/# ip a sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 100
    link/ether 00:25:90:09:52:8e brd ff:ff:ff:ff:ff:ff
    inet yyy.162.190.160/24 brd yyy.162.190.255 scope global eth0
    inet yyy.162.142.136/16 brd yyy.162.255.255 scope global eth0:0
       valid_lft forever preferred_lft foreve
root@server:/# 

Proxy (Ip proxy: bbb.162.182.110)
# Generated by iptables-save v1.3.5 on Thu Aug  4 16:14:05 2011
*filter
:INPUT ACCEPT [57:4813]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [38:3912]
-A FORWARD -d yyy.162.190.160 -i eth0 -o eth0 -p tcp -m tcp --dport 8888 -j ACCEPT 
COMMIT
# Completed on Thu Aug  4 16:14:05 2011
# Generated by iptables-save v1.3.5 on Thu Aug  4 16:14:05 2011
*nat
:PREROUTING ACCEPT [14:989]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -d bbb.162.182.110 -p tcp -m tcp --dport 8888 -j DNAT --to-destination yyy.162.190.160:8888 
-A OUTPUT -d bbb.162.182.110 -p tcp -m tcp --dport 8888 -j DNAT --to-destination yyy.162.190.160 
COMMIT
# Completed on Thu Aug  4 16:14:05 2011

В данном случае для тестов осуществляется проброс порта 8888 с прокси на него же на сервере. Но в реальных условиях нужно иметь возможность использовать любые комбинации портов

Вери нид хелп, уже вторые сутки себе мозг ломаю

boombick ★★★★★
() автор топика

Кто мешает поставить на proxy nginx или apache в минимальной конфигурации?

для nginx:

server {
    listen 80;
    location / {
        proxy_path http://server:2220;
        proxy_set_header Host $host;
        # или proxy_set_header Host $host:$server_port;
        proxy_set_header X-Real-IP  $remote_addr;
    }
    access_log /var/log/nginx/server_2220_access.log main
    error_log /var/log/nginx/server_2220_error.log debug;
}
router ★★★★★
()
Ответ на: комментарий от router

а nginx умеет проксировать long-polling запросы? Вообще, хотелось бы сделать проброс именно средствами iptables

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

>long-polling

Никогда не сталкивался. Может и не умеет.

Вообще, хотелось бы сделать проброс именно средствами iptables

Тогда тебе придётся, ИМХО, связываться с динамической маршрутизацией. Сейчас подумаю и напишу команды

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

Делайте между «proxy» и сервеом VPN и как здесь: http://www.linux.org.ru/forum/admin/6566960

Или рулите маршрутизацией через «iptables MARK/CONNMARK + ip rule fwmark», но если proxy не в одном hop'e от сервера, то всё равно нужет будет тунель.

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

Proxy. обычная статическая маршрутизация

iptables -A PREROUTING -d bbb.162.182.110 -p tcp -m tcp --dport 8888 -j DNAT --to-destination yyy.162.190.160:8888 

Server. Динамическая маршрутизация.

тебе нужно определить, что пакет пришёл именно с прокси. Тебе виднее, как определить, я тупо взял порт

# помечаем соединение
iptables -t mangle -A PREROUTING -p tcp -m tcp --dport 8888 -j CONNMARK --set-mark 1
# переносим метку соединения на пакет
iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark

Добавляешь в /etc/iproute2/rt_tables

<уникальная цифра> proxy1

затем добавляешь правило: все пакеты с меткой 1 пойдут через таблицу маршрутизации proxy1

ip rule add fwmark 1 table proxy1

ну и банальный маршрут до сети и маршрут по умолчанию в этой таблице:

ip r add yyy.162.190.0/24 dev ethX proto kernel scope link src yyy.162.190.160 table proxy1
ip r add default via yyy.162.190.1 table proxy1
router ★★★★★
()
Ответ на: комментарий от boombick

Учти, mky абсолютно прав, если между server и proxy есть ещё хопы, приведённый мной вариант не будет работать. Потребуется создавать туннель между proxy и server и трафик из таблицы маршрутизации proxy1 заворачивать в туннель

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

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

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

Всё что тебе нужно - ответы отправлять обратно через proxy. Если сможешь сделать это проще - прекрасно :)

А если ответы пойдут мимо прокси, то с точки зрения клиента бардак: он подключается к proxy, тот не отвечает, зато с какого-то левого ip приходит пакет c SYN,ACK

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

Идеологически верным будет nginx если там веб. А на бекенде вытаскивать ип клиента из заголовка который впишет нгинкс. А то туннели это несколько как то костыльно для такой задачи имхо.

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

Я nginx и предлагал. Некий «long-polling» в этом случае возможен?

а nginx умеет проксировать long-polling запросы?

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

Я не специалист в вебе, но чето мне кажется что возможен, думается рассылка нгинкс точно может ответить на этот вопрос.

ventilator ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.