Переадресация портов с сохранением исходного IP-адреса?
У меня есть выделенный сервер, на котором все работает, однако на dedi отсутствует защита от 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, однако есть одна проблема. 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
Dedi:
Результат из 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
Если вы хотите, чтобы прокси-сервер видел IP-адреса, прокси-сервер должен быть шлюзом для прокси-сервера.
У вашего 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, помимо разрешения только одной службы, ...