LINUX.ORG.RU
ФорумAdmin

Проброс порта не через шлюз

 , , ,


0

1

Приветствую. Возникла проблема проброса портов наружу через туннель.
Логика работы следующая: На удаленный IP приходят запросы на подключение к определенным портам; запросы переадресовываются через туннель к локальному узлу который не есть шлюзом по-умолчанию в сети; локальный узел переадресовывает запросы на соседа по сети с подстановкой IP-источника запроса на себя, чтобы сосед отвечал в туннель, а не через шлюз.
Внутренняя сеть с выходом в Интернет: 192.168.0.0/24 gw 192.168.0.1
Во внутренний сети:

  • 192.168.0.51 — узел с поднятым туннелем
  • 192.168.0.252 — хост на которого нужно пробросить 80,554,8000,9010

Туннель:

  • 192.168.2.1 — сервер с pptpd (он же 90.90.90.90)
  • 192.168.2.2 — клиент pptp (он же 192.168.0.51)

На удаленной машине (90.90.90.90):

# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -P PREROUTING ACCEPT
# iptables -P FORWARD ACCEPT
# iptables -P POSTROUTING ACCEPT
# iptables -t nat -A PREROUTING -d 90.90.90.90/32 -p tcp -m tcp --dport 8000 -j DNAT --to-destination 192.168.2.2:80
# iptables -t nat -A PREROUTING -d 90.90.90.90/32 -p tcp -m tcp --dport 554 -j DNAT --to-destination 192.168.2.2:554
# iptables -t nat -A PREROUTING -d 90.90.90.90/32 -p tcp -m tcp --dport 8000 -j DNAT --to-destination 192.168.2.2:8000
# iptables -t nat -A PREROUTING -d 90.90.90.90/32 -p tcp -m tcp --dport 9010 -j DNAT --to-destination 192.168.2.2:9010
# iptables -t mangle -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
# iptables -t nat -A POSTROUTING -d 192.168.2.2/32 -p tcp -m tcp --dport 80 -j SNAT --to-source 90.90.90.90
# iptables -t nat -A POSTROUTING -d 192.168.2.2/32 -p tcp -m tcp --dport 554 -j SNAT --to-source 90.90.90.90
# iptables -t nat -A POSTROUTING -d 192.168.2.2/32 -p tcp -m tcp --dport 8000 -j SNAT --to-source 90.90.90.90
# iptables -t nat -A POSTROUTING -d 192.168.2.2/32 -p tcp -m tcp --dport 9010 -j SNAT --to-source 90.90.90.90
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE


На локальном хосте 192.168.0.51:
# echo 1 > /proc/sys/net/ipv4/ip_forward
# iptables -P PREROUTING ACCEPT
# iptables -P FORWARD ACCEPT
# iptables -P POSTROUTING ACCEPT
# iptables -t nat -A PREROUTING -p tcp -d 192.168.2.2 --dport 80 -j DNAT --to-destination 192.168.0.252:80
# iptables -t nat -A PREROUTING -p tcp -d 192.168.2.2 --dport 554 -j DNAT --to-destination 192.168.0.252:554
# iptables -t nat -A PREROUTING -p tcp -d 192.168.2.2 --dport 8000 -j DNAT --to-destination 192.168.0.252:8000
# iptables -t nat -A PREROUTING -p tcp -d 192.168.2.2 --dport 9010 -j DNAT --to-destination 192.168.0.252:9010
# iptables -t nat -A POSTROUTING -p tcp -d 192.168.0.252 --dport 80 -j SNAT --to-source 192.168.0.51
# iptables -t nat -A POSTROUTING -p tcp -d 192.168.0.252 --dport 554 -j SNAT --to-source 192.168.0.51
# iptables -t nat -A POSTROUTING -p tcp -d 192.168.0.252 --dport 8000 -j SNAT --to-source 192.168.0.51
# iptables -t nat -A POSTROUTING -p tcp -d 192.168.0.252 --dport 9010 -j SNAT --to-source 192.168.0.51
# iptables -t nat -A POSTROUTING -o ppp+ -j MASQUERADE

Некоторые выводы програм:
user@192.168.0.51:~$ nmap 192.168.0.252
Starting Nmap 7.01 ( https://nmap.org ) at 2018-02-12 13:44 EET
Nmap scan report for 192.168.0.252
Host is up (0.0019s latency).
Not shown: 995 closed ports
PORT      STATE SERVICE
80/tcp    open  http
554/tcp   open  rtsp
8000/tcp  open  http-alt
9010/tcp  open  sdr
user@90.90.90.90:~$ nmap 192.168.2.2

Starting Nmap 7.01 ( https://nmap.org ) at 2018-02-12 12:00 UTC
Nmap scan report for 192.168.2.2
Host is up (0.057s latency).
Not shown: 992 closed ports
PORT     STATE    SERVICE
22/tcp   open     ssh
80/tcp   filtered http
81/tcp   filtered hosts2-ns
139/tcp  open     netbios-ssn
445/tcp  open     microsoft-ds
554/tcp  filtered rtsp
8000/tcp filtered http-alt
8200/tcp filtered trivnet1

Подключался к туннелю с вендовой машины на которой просто открыты 80,554,8000,9010 то удаленная машина нормально пробрасывает. Предполагаю, что проблема с локальным узлом (192.168.0.51). Подскажите, в чем проблема.

В чем у тебя проблема? Трафик через туннель не доходит до 192.168.0.252?

Если да, то проверь правила в цепочке FORWARD на 192.168.0.51. Вообще бы желательно видеть все правила в выводе iptables-save

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

Проблема в том, что трафик через туннель ПРИходит, но я так полагаю, что локальная машина не отвечает. Политика цепочки FORWARD ACCEPT

root@192.168.0.51:/# iptables-save
# Generated by iptables-save v1.6.0 on Mon Feb 12 15:39:59 2018
*filter
:INPUT ACCEPT [258:22962]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [204:24715]
COMMIT
# Completed on Mon Feb 12 15:39:59 2018
# Generated by iptables-save v1.6.0 on Mon Feb 12 15:39:59 2018
*nat
:PREROUTING ACCEPT [1222:67294]
:INPUT ACCEPT [1189:65722]
:OUTPUT ACCEPT [52:5793]
:POSTROUTING ACCEPT [12:2159]
-A PREROUTING -d 192.168.2.2/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.0.252:80
-A PREROUTING -d 192.168.2.2/32 -p tcp -m tcp --dport 554 -j DNAT --to-destination 192.168.0.252:554
-A PREROUTING -d 192.168.2.2/32 -p tcp -m tcp --dport 8000 -j DNAT --to-destination 192.168.0.252:8000
-A PREROUTING -d 192.168.2.2/32 -p tcp -m tcp --dport 9010 -j DNAT --to-destination 192.168.0.252:9010
-A POSTROUTING -d 192.168.0.252/32 -p tcp -m tcp --dport 80 -j SNAT --to-source 192.168.0.51
-A POSTROUTING -d 192.168.0.252/32 -p tcp -m tcp --dport 554 -j SNAT --to-source 192.168.0.51
-A POSTROUTING -d 192.168.0.252/32 -p tcp -m tcp --dport 8000 -j SNAT --to-source 192.168.0.51
-A POSTROUTING -d 192.168.0.252/32 -p tcp -m tcp --dport 9010 -j SNAT --to-source 192.168.0.51
-A POSTROUTING -o ppp+ -j MASQUERADE
COMMIT
# Completed on Mon Feb 12 15:39:59 2018

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

Попробуй половить пакеты tcpdump'ом на 192.168.0.51, точно ли трафик уходит на целевую машину. Входящие через pptp и выходящие в локалку:

tcpdump -i ppp0 -nnp 'port 80 or port 554 or port 8000 or port 9010'
tcpdump -i eth0 -nnp 'port 80 or port 554 or port 8000 or port 9010'

Deleted ()
Ответ на: комментарий от Deleted
root@ubuntuVM:/# tcpdump -i ppp0 -nnp 'port 80 or port 554 or port 8000 or port 9010'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
16:31:14.545575 IP 90.90.90.90.35432 > 192.168.2.2.8000: Flags [S], seq 3683077941, win 13140, options [mss 1400,sackOK,TS val 20455992 ecr 0,nop,wscale 6], length 0
16:31:14.604575 IP 90.90.90.90.35432 > 192.168.2.2.8000: Flags [S], seq 3683077941, win 13140, options [mss 1400,sackOK,TS val 20456093 ecr 0,nop,wscale 6], length 0
16:31:15.865237 IP 90.90.90.90.35432 > 192.168.2.2.8000: Flags [S], seq 3683077941, win 13140, options [mss 1400,sackOK,TS val 20456293 ecr 0,nop,wscale 6], length 0
16:31:20.281463 IP 90.90.90.90.35432 > 192.168.2.2.8000: Flags [S], seq 3683077941, win 13140, options [mss 1400,sackOK,TS val 20456694 ecr 0,nop,wscale 6], length 0

На физическом интерфейсе (enp0s3) молчание.

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

Значит, форвардинг не работает. В /proc/sys/net/ipv4/ip_forward стоит 1?

Также, на 192.168.0.51 должен быть либо маршрут до 90.90.90.90 через pptp, либо дефолтный маршрут через pptp. Иначе трафик будет дропаться rp_filter'ом, что похоже на твой случай.

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

На 192.168.0.51 форвардинг включен?

echo 1 > /proc/sys/net/ipv4/ip_forward

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

Также, на 192.168.0.51 должен быть либо маршрут до 90.90.90.90 через pptp, либо дефолтный маршрут через pptp.

Кстати да. Или еще вот эти правила подправить в части --to-source

 iptables -t nat -A POSTROUTING -d 192.168.2.2/32 -p tcp -m tcp --dport 80 -j SNAT --to-source 90.90.90.90

anc ★★★★★ ()
Ответ на: комментарий от Deleted
root@192.168.0.51:/# route
Таблица маршутизации ядра протокола IP
Destination Gateway Genmask Flags Metric Ref Use Iface
default         *               0.0.0.0         U     0      0        0 ppp0
192.168.0.0     *               255.255.255.0   U     0      0        0 enp0s3
192.168.2.1     *               255.255.255.255 UH    0      0        0 ppp0
90.90.90.90.  192.168.0.1       255.255.255.255 UGH   0      0        0 enp0s3
root@192.168.0.51:/# cat /proc/sys/net/ipv4/ip_forward
1
kolider ()
Ответ на: комментарий от kolider

90.90.90.90. 192.168.0.1 255.255.255.255 UGH 0 0 0 enp0s3

Похоже, что данный маршрут там специально. Тогда должно помочь изменение правил SNAT на 90.90.90.90, с

--to-source 90.90.90.90
на
--to-source 192.168.2.1

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

Стоит дефолтный маршрут на туннель. Что не так со строчкой --to-source?
Вот iptables-save с удаленки

root@90.90.90.90:/home/orangepi# iptables-save
# Generated by iptables-save v1.6.0 on Mon Feb 12 15:59:53 2018
*security
:INPUT ACCEPT [37:2632]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [22:2096]
COMMIT
# Completed on Mon Feb 12 15:59:53 2018
# Generated by iptables-save v1.6.0 on Mon Feb 12 15:59:53 2018
*raw
:PREROUTING ACCEPT [38:2861]
:OUTPUT ACCEPT [24:2416]
COMMIT
# Completed on Mon Feb 12 15:59:53 2018
# Generated by iptables-save v1.6.0 on Mon Feb 12 15:59:53 2018
*nat
:PREROUTING ACCEPT [1:229]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A PREROUTING -d 90.90.90.90/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.2.2:80
-A PREROUTING -d 90.90.90.90/32 -p tcp -m tcp --dport 554 -j DNAT --to-destination 192.168.2.2:554
-A PREROUTING -d 90.90.90.90/32 -p tcp -m tcp --dport 8000 -j DNAT --to-destination 192.168.2.2:8000
-A PREROUTING -d 90.90.90.90/32 -p tcp -m tcp --dport 9010 -j DNAT --to-destination 192.168.2.2:9010
-A POSTROUTING -d 192.168.2.2/32 -p tcp -m tcp --dport 80 -j SNAT --to-source 90.90.90.90
-A POSTROUTING -d 192.168.2.2/32 -p tcp -m tcp --dport 554 -j SNAT --to-source 90.90.90.90
-A POSTROUTING -d 192.168.2.2/32 -p tcp -m tcp --dport 8000 -j SNAT --to-source 90.90.90.90
-A POSTROUTING -d 192.168.2.2/32 -p tcp -m tcp --dport 9010 -j SNAT --to-source 90.90.90.90
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Mon Feb 12 15:59:53 2018
# Generated by iptables-save v1.6.0 on Mon Feb 12 15:59:53 2018
*mangle
:PREROUTING ACCEPT [38:2861]
:INPUT ACCEPT [37:2632]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [31:3608]
:POSTROUTING ACCEPT [31:3608]
-A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
COMMIT
# Completed on Mon Feb 12 15:59:53 2018
# Generated by iptables-save v1.6.0 on Mon Feb 12 15:59:53 2018
*filter
:INPUT ACCEPT [37:2632]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [31:3608]
-A INPUT -s 192.168.1.0/24 -i enx00808c8e3485 -j ACCEPT
-A INPUT -s 192.168.2.0/24 -i ppp+ -j ACCEPT
-A INPUT -p tcp -m tcp --dport 1723 -j ACCEPT
-A FORWARD -i eth0 -j ACCEPT
COMMIT
# Completed on Mon Feb 12 15:59:53 2018

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

Что не так со строчкой --to-source

Поменяйте на ip тунеля (предполагаю что 192.168.2.1). Либо просто маскарад одной строчкой

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

Разве маскарад не включен строкой в таблице nat?
-A POSTROUTING -o eth0 -j MASQUERADE

Действительно трафик побежал после изменения источника (--to-source). Производительность такого соединения получилось как на диалапе. Ранее встречал проблему скорости через туннель, решилось iptables -t mangle -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Повторил данную процедуру на локальном хосте но лучше не стало.

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

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

Разве маскарад не включен строкой в таблице nat?
-A POSTROUTING -o eth0 -j MASQUERADE

Я писал про другой, который с ppp уходит. Но все нормально, раз работает, просто некоторые ошибаются в части ip, я же только предположил что это 192.168.2.1.

Действительно трафик побежал после изменения источника (--to-source). Производительность такого соединения получилось как на диалапе.

Подкол. А вы диалап реально использовали в жизни? А то 2400/none это тоже диалап. :)
По теме. Ловите, где, что, теряется между узлами. Я бы начал ipref3 между точками.

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

Ловите, где, что, теряется между узлами

Я бы больше поставил на производительность pptp-сервера, который, судя по юзернейму (orangepi), является одноплатником.

2ТС: понаблюдай за нагрузкой на сервер во время прокачки большого трафика, можно просто утилитой top. Инкапсуляция/декапсуляция пакетов отнимает много ресурсов.

Как вариант, можно заюзать опцию ядра CONFIG_PPTP вместе с accel-pptp, но сам я этого не делал, так что детальней не подскажу.

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

Я бы больше поставил на производительность pptp-сервера, который, судя по юзернейму (orangepi), является одноплатником.

Вы правы трижды. Плюсану за это.

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

трижды

Тогда хватит на сегодня, пожалуй, не буду слишком наглеть %)

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

Спасибо slvrn попробую, Вы решили вопрос. Отдельная благодарность anc, тест ширины канала без туннеля до 1,5Mb/s. Вопрос скорости решен вернее отпал сам собой.

Оффтоп: соединение прова с одноплатником 1Gb (orangepi zero plus); пров дает ~300Mb по speedtest.net; расшарен инет через usb-свисток 100Mb(enx00808c8e3485) жаль нет usb3.0; скорость http://www.speedtest.net/result/7052984081 и top: load average 1.72, 1.28, 1.18

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

Могу сильно ошибаться, с одноплатниками не развлекался. Но все-таки, LA 1.72 для одноплатника не перебор? Или это нормально? Просто интересно даже.

ЗЫ Предупреждая не нужные комментарии, я в курсе что LA это не только процессор.

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

Проброс второй вариант

Со временем провайдер урезал использование GRE по этому пришлось думать дальше. Порывшись в инете нашел реализацию через ssh и написал небольшой скрипт

#!/bin/bash
ADDRESS="90.90.90.90"
LOCAL_IP="192.168.0.252"
PORTS="80 554 8000 9010"
USR="root"
PASSWD="pass"

function checkPort() {
	local address=$1
	local prt=$2
	timeout 2 bash -c "cat < /dev/null > /dev/tcp/$address/$prt 2> /dev/null"
	if [ "$?" -ne 0 ]; then
	  return 1
	else
	  return 0
	fi
}

function connectPort (){
	sshpass -p $PASSWD ssh -o StrictHostKeyChecking=no -f -R \*:$2:$LOCAL_IP:$2 -N $USR@$1 -p 22
}

for port in $PORTS
do
        checkPort $ADDRESS $port
        if [ "$?" -ne 0 ]; then
        logger -t PortForwarding -i "Выпол. проброс для $port порта"
	connectPort $ADDRESS $port
        fi
done
Знаю, что парольная аутентификация не безопасна и к тому же еще от рута. Для использования до 4-х значного порта нужно привилегии рута. Пока так. С открытыми ключами просто не разобрался

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