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

Перенаправлять запросы на конкретный порт VPN-клиенту

У меня проблема, когда мне нужна поддержка, но самое сложное в том, что я не знаю, ГДЕ это неправильно. У меня есть Raspberry Pi с Ubuntu Server, работающим в моей домашней сети, и VPS с Ubuntu Server на хост-сервере. Raspberry Pi имеет клиент OpenVPN, а VPS - сервер OpenVPN. Клиент подключен к серверу, так как я вижу его в /var/log/openvpn/openvpn-status.log.

OpenVPN CLIENT LIST
Updated,Sun Feb 16 09:41:43 2020
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
client1,37.201.227.34:28237,3610,3478,Sun Feb 16 09:41:38 2020
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
10.8.0.6,client1,37.201.227.34:28237,Sun Feb 16 09:41:38 2020
GLOBAL STATS
Max bcast/mcast queue length,0
END

Я хочу перенаправить запросы на VPS с портом 9000 клиенту VPN. Однако всегда истекает время ожидания, как будто он не пересылает запрос.

у меня есть net.ipv4.ip_forward = 1 установлен в sysctl, и это содержимое /etc/ufw/before.rules (Я также пробовал обменять 37.201.xxx на 10.8.0.6, но безуспешно)

#
# rules.before
#
# Rules that should be run before the ufw command line added rules. Custom
# rules should be added to one of these chains:
#   ufw-before-input
#   ufw-before-output
#   ufw-before-forward
#

# START OPENVPN RULES
# NAT table rules
*nat
:POSTROUTING ACCEPT [0:0]

-A PREROUTING -i venet0 -p tcp -m tcp --dport 9000 -j DNAT --to-destination 37.201.227.34:9000
-A PREROUTING -i venet0 -p udp -m udp --dport 9000 -j DNAT --to-destination 37.201.227.34:9000

# Allow traffic from OpenVPN client to venet0 (change to the interface you discovered!)
-A POSTROUTING -s 10.8.0.0/8 -o venet0 -j MASQUERADE
COMMIT
# END OPENVPN RULES

# Don't delete these required lines, otherwise there will be errors
*filter
:ufw-before-input - [0:0]
:ufw-before-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-not-local - [0:0]
# End required lines


# allow all on loopback
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-output -o lo -j ACCEPT

# quickly process packets for which we already have a connection
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# drop INVALID packets (logs these in loglevel medium and higher)
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP

# ok icmp codes for INPUT
-A ufw-before-input -p icmp --icmp-type destination-unreachable -j ACCEPT
-A ufw-before-input -p icmp --icmp-type time-exceeded -j ACCEPT
-A ufw-before-input -p icmp --icmp-type parameter-problem -j ACCEPT
-A ufw-before-input -p icmp --icmp-type echo-request -j ACCEPT

# ok icmp code for FORWARD
-A ufw-before-forward -p icmp --icmp-type destination-unreachable -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type time-exceeded -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type parameter-problem -j ACCEPT
-A ufw-before-forward -p icmp --icmp-type echo-request -j ACCEPT

# allow dhcp client to work
-A ufw-before-input -p udp --sport 67 --dport 68 -j ACCEPT

#
# ufw-not-local
#
-A ufw-before-input -j ufw-not-local

# if LOCAL, RETURN
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN

# if MULTICAST, RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN

# if BROADCAST, RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN

# all other non-local packets are dropped
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP

# allow MULTICAST mDNS for service discovery (be sure the MULTICAST line above
# is uncommented)
-A ufw-before-input -p udp -d 224.0.0.251 --dport 5353 -j ACCEPT

# allow MULTICAST UPnP for service discovery (be sure the MULTICAST line above
# is uncommented)
-A ufw-before-input -p udp -d 239.255.255.250 --dport 1900 -j ACCEPT

# START OPENVPN RULES
-A FORWARD -d 37.201.227.34/32 -p tcp -m tcp --dport 9000 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -d 37.201.227.34/32 -p udp-m udp --dport 9000 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
# END OPENVPN RULES

# don't delete the 'COMMIT' line or these rules won't be processed
COMMIT

В моем маршрутизаторе (кабель AVM FritzBox 6591) у меня есть переадресация порта для порта 9000 на мой активный raspberry pi, как вы можете видеть на этом снимке экрана.

Однако, когда я ввожу «VPSIP: 9000» в своем браузере, время ожидания просто истекает. Где что-то не так?

Если на Raspberry Pi работает клиент OpenVPN, вам не нужно открывать порт на маршрутизаторе FritzBox. Однако правильное правило iptables в PREROUTING - это правило с 10.8.0.6 в качестве пункта назначения.

# START OPENVPN RULES
# NAT table rules
*nat
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -i venet0 -p tcp -m tcp --dport 9000 -j DNAT --to-destination 10.8.0.6:9000
-A PREROUTING -i venet0 -p udp -m udp --dport 9000 -j DNAT --to-destination 10.8.0.6:9000

Проблема с тайм-аутом соединения заключается в том, что Raspberry Pi получает запрос через VPN с общедоступным IP-адресом, поэтому ответные пакеты будут проходить через Raspberry Pi Ethernet (или интерфейс Wi-Fi), потому что у него нет правила маршрутизации для ответьте через интерфейс VPN. Чтобы ничего не трогать на RaspberryPi, вы можете решить эту проблему, замаскировав WAN-трафик VPS с IP-адресом VPN-сервера. Пример ниже:

-A POSTROUTING -o <vpn-server-interface> -j SNAT --to-source 10.8.0.1

Raspberry Pi увидит запрос, поступающий с IP-адреса VPN-сервера (при условии, что это 10.8.0.1). Поэтому в файле /etc/ufw/before.rules должно быть указано

# START OPENVPN RULES
# NAT table rules
*nat
:POSTROUTING ACCEPT [0:0]

-A PREROUTING -i venet0 -p tcp -m tcp --dport 9000 -j DNAT --to-destination 10.8.0.6:9000
-A PREROUTING -i venet0 -p udp -m udp --dport 9000 -j DNAT --to-destination 10.8.0.6:9000

# Allow traffic from OpenVPN client to venet0 (change to the interface you discovered!)
-A POSTROUTING -o <vpn-server-interface> -j SNAT --to-source 10.8.0.1
-A POSTROUTING -s 10.8.0.0/8 -o venet0 -j MASQUERADE
COMMIT
# END OPENVPN RULES

Примечание: Недостатком этого решения является то, что в журналах приложения portainer вы увидите весь запрос с IP-адресом VPN-сервера.

РЕДАКТИРОВАТЬ: ИМХО, лучший способ добиться этого - использовать nginx или apache на VPS в качестве обратного прокси, таким образом вам не нужно настраивать какие-либо правила предварительной и последующей маршрутизации iptables, а также у вас будут на обратном прокси-сервере журналы с клиентами реальные IP