Назад | Перейти на главную страницу

Перенаправление портов с сохранением исходного IP-адреса?

У меня есть выделенный сервер, на котором все работает, но деди не имеет защиты от DDoS-атак, поэтому я купил VPS, который идет с ним, поэтому я могу эффективно использовать его в качестве прокси.

У меня есть настройка переадресации портов на VPS с помощью следующих команд:

iptables -t nat -A PREROUTING -p tcp --dport 30001 -j DNAT --to-destination DEDIIP:30001
iptables -t nat -A POSTROUTING -p tcp -d DEDIIP --dport 21 -j SNAT --to-source VPSIP

Подключение к VPSIP работает и подключает меня к деди, но есть одна проблема. Dedi показывает, что каждое соединение происходит с одного и того же IP-адреса (VPS). Есть ли способ сохранить исходный?

Например:

Now:

CLIENT --> VPS --> Dedi (Shows the clients IP as the VPS)

What I need it to be like

CLIENT --> VPS --> Dedi (Shows the clients IP, just as if the VPS wasn't there)

Кто-нибудь знает, как это сделать, или где я ошибся?

Отредактируйте, чтобы предоставить дополнительную информацию:

VPS:

Результат ip route show

default via xxx.xxx.xxx.1 dev ens3
xxx.xxx.xxx.0/24 dev ens3  proto kernel  scope link  src xxx.xxx.xxx.138

Результат ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 06:d4:28:00:08:6e brd ff:ff:ff:ff:ff:ff
    inet xxx.xxx.xxx.138/24 brd xxx.xxx.xxx.255 scope global ens3
       valid_lft forever preferred_lft forever
    inet6 fe80::4d4:28ff:fe00:86e/64 scope link
       valid_lft forever preferred_lft forever

IPTables:

# Generated by iptables-save v1.6.0 on Tue Nov 29 20:18:46 2016
*nat
:PREROUTING ACCEPT [18637:1487446]
:INPUT ACCEPT [1420:143605]
:OUTPUT ACCEPT [3:228]
:POSTROUTING ACCEPT [8:496]
-A PREROUTING -p tcp -m tcp --dport 21 -j DNAT --to-destination xxx.xxx.xxx.147:30001
-A POSTROUTING -d xxx.xxx.xxx.147/32 -p tcp -m tcp --dport 30001 -j SNAT --to-source xxx.xxx.xxx.138
COMMIT
# Completed on Tue Nov 29 20:18:46 2016
# Generated by iptables-save v1.6.0 on Tue Nov 29 20:18:46 2016
*filter
:INPUT ACCEPT [16718:1768066]
:FORWARD ACCEPT [2016:3102889]
:OUTPUT ACCEPT [11789:4503936]
COMMIT

Деди:

Результат ip route show

default via xxx.xxx.xxx.254 dev eth0 onlink
xxx.xxx.xxx.0/24 dev eth0  proto kernel  scope link  src xxx.xxx.xxx.147

Результат ip addr

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    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 group default qlen 1000
    link/ether e0:cb:4e:8c:ab:5d brd ff:ff:ff:ff:ff:ff
    inet xxx.xxx.xxx.147/24 brd xxx.xxx.xxx.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 2001:41d0:8:1a93::/64 scope global
       valid_lft forever preferred_lft forever
    inet6 fe80::e2cb:4eff:fe8c:ab5d/64 scope link
       valid_lft forever preferred_lft forever

IPTables:

*filter
:INPUT ACCEPT [31996807:9076994683]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [35073288:16420652529]
:ufw-after-forward - [0:0]
:ufw-after-input - [0:0]
:ufw-after-logging-forward - [0:0]
:ufw-after-logging-input - [0:0]
:ufw-after-logging-output - [0:0]
:ufw-after-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-before-input - [0:0]
:ufw-before-logging-forward - [0:0]
:ufw-before-logging-input - [0:0]
:ufw-before-logging-output - [0:0]
:ufw-before-output - [0:0]
:ufw-reject-forward - [0:0]
:ufw-reject-input - [0:0]
:ufw-reject-output - [0:0]
:ufw-track-forward - [0:0]
:ufw-track-input - [0:0]
:ufw-track-output - [0:0]
-A INPUT -j ufw-before-logging-input
-A INPUT -j ufw-before-input
-A INPUT -j ufw-after-input
-A INPUT -j ufw-after-logging-input
-A INPUT -j ufw-reject-input
-A INPUT -j ufw-track-input
-A FORWARD -j ufw-before-logging-forward
-A FORWARD -j ufw-before-forward
-A FORWARD -j ufw-after-forward
-A FORWARD -j ufw-after-logging-forward
-A FORWARD -j ufw-reject-forward
-A FORWARD -j ufw-track-forward
-A OUTPUT -j ufw-before-logging-output
-A OUTPUT -j ufw-before-output
-A OUTPUT -j ufw-after-output
-A OUTPUT -j ufw-after-logging-output
-A OUTPUT -j ufw-reject-output
-A OUTPUT -j ufw-track-output
COMMIT

У вашего Dedi есть маршрутизатор по умолчанию xxx.xxx.xxx.254, который не является VPS, назовем его R

Если вы не использовали SNAT в VPS (чтобы реальный IP-адрес поступил на Dedi), то вот что произойдет, когда клиент C подключится к службе FTP на IP-адресе VPS:

C --> VPS --> Dedi
 ^            /
  \<-- R  <--/

Клиент C инициирует соединение с VPS, но ответ на соединение будет приходить с другого IP-адреса, о котором C. Даже если бы все использовали один и тот же общедоступный IP-адрес (я не знаю об этом маршрутизаторе R и его отношении к VPS), порт все равно был бы неправильным (30001 вместо 21). C отправит пакет RST (сброс). Соединение никогда не установится.

Итак, как говорилось ранее, единственный способ заставить его работать должным образом - это заставить VPS видеть как входящий, так и исходящий поток между клиентом C и Dedi. В настоящее время это реализовано путем предоставления каждой стороне своего собственного IP-адреса, а на стороне Dedi требуется SNAT. Если бы VPS был маршрутизатором по умолчанию для Dedi, тогда ему не пришлось бы изменять IP-адрес клиента, чтобы получить исходящий поток.

Теперь несколько замечаний:

нигде нет правила межсетевого экрана, по умолчанию все принимается. VPS пересылает только FTP и ничего больше, так что это нормально. Если VPS должен был быть маршрутизатором по умолчанию, должны быть добавлены правила брандмауэра, а также правила NAT, если Dedi не является общедоступным, и для политики по умолчанию, возможно, придется установить DROP.
если вы сделаете такие изменения, ожидайте потери сетевого доступа к Dedi. Во время этих изменений вам понадобится прямой доступ к консоли, предоставляемый вашим хостинговым решением.
там много неизвестного. Сколько из них имеют общедоступные IP-адреса по сравнению с частными, каким образом VPS предотвращает DDoS-атаки на Dedi, помимо разрешения только одной службы, ...

Прокси-сервер должен быть шлюзом для прокси-сервера, если вы хотите, чтобы прокси-сервер видел IP-адреса.