LINUX.ORG.RU
решено Форум — Admin  

Iptables (снова про проброс портов)

 ,


0

1

Дано: debian в локалке 192.168.1.0/24 с интерфейсом ens192 и туннель openvpn tun0 в далёкую даль

1: lo: ....
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0c:29:d3:80:59 brd ff:ff:ff:ff:ff:ff
    altname enp11s0
    inet 192.168.1.65/24 brd 192.168.1.255 scope global ens192
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fed3:8059/64 scope link
       valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500
    link/none
    inet 10.8.0.66/24 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::6e6d:bf82:7e44:afe6/64 scope link stable-privacy
       valid_lft forever preferred_lft forever

Задача: нужно чтобы пользователи openvpn (10.8.0.0/24) имели доступ к 192.168.1.66 по https (это другая машина в локалке), если вводят в браузере https://10.8.0.66:443 (это наш debian в подсети openvpn)

Клиенты openvpn друг друга видят без проблем.

Хотел пробросить порты в iptables, но не работает. Остальное в iptables по умолчанию (всё открыто).

iptables -A FORWARD -i tun0 -o ens192 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -d 10.8.0.66 --dport 443 -j DNAT --to-destination 192.168.1.66:443
iptables -t nat -A POSTROUTING -p tcp --sport 443 --dst 192.168.1.66 -j SNAT --to-source 10.8.0.66:443

Смотрел через tcpdump - пакеты нормально долетают из tun0, а потом летят на 192.168.1.66, но в ответ тишина.

Помогите, пожалуйста. Голову сломал уже.


альтернативный вариант: установить nginx как реверс-прокси на адрес 10.8.0.66

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

Исправил, но не помогло( 

tcpdump port 443 -i ens192
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens192, link-type EN10MB (Ethernet), snapshot length 262144 bytes
07:45:35.187104 IP 10.8.0.2.54591 > 192.168.1.66.https: Flags [S], seq 1544433926, win 64240, options [mss 1358,nop,wscale 8,nop,nop,sackOK], length 0
07:45:35.187150 IP 10.8.0.2.54592 > 192.168.1.66.https: Flags [S], seq 1638854419, win 64240, options [mss 1358,nop,wscale 8,nop,nop,sackOK], length 0
07:45:35.437530 IP 10.8.0.2.54593 > 192.168.1.66.https: Flags [S], seq 2285114017, win 64240, options [mss 1358,nop,wscale 8,nop,nop,sackOK], length 0

tcpdump port 443 -i tun0
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on tun0, link-type RAW (Raw IP), snapshot length 262144 bytes
07:47:10.781788 IP 10.8.0.2.54731 > ovpn-tunnel.https: Flags [S], seq 222153586, win 64240, options [mss 1358,nop,wscale 8,nop,nop,sackOK], length 0
07:47:10.781912 IP 10.8.0.2.54732 > ovpn-tunnel.https: Flags [S], seq 4246392654, win 64240, options [mss 1358,nop,wscale 8,nop,nop,sackOK], length 0
07:47:11.032943 IP 10.8.0.2.54733 > ovpn-tunnel.https: Flags [S], seq 1914391765, win 64240, options [mss 1358,nop,wscale 8,nop,nop,sackOK], length 0

Про nginx думал, но мне надо еще по RDP машину из локалки по такой же схеме пробросить, поэтому nginx не подходит (

dst123
() автор топика
Ответ на: комментарий от dst123
  1. run tcpdump on 192.168.1.66

пакеты должны приходить с адреса 192.168.1.65, а не 10.8.0.2

  1. когда пакеты начнут возвращаться понадобится доп. правило

iptables -A FORWARD -o tun0 -i ens192 -j ACCEPT

futurama ★★★★★
()
Последнее исправление: futurama (всего исправлений: 1)
Ответ на: комментарий от futurama

Вы совершенно правы. Запустил tcpdump на 192.168.1.66, пакеты долетают, но приходят с 10.8.0.2, а не с 192.168.1.65

Подскажите, как исправить?

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

replace

iptables -t nat -A POSTROUTING -p tcp –sport 443 –dst 192.168.1.66 -j SNAT –to-source 10.8.0.66:443

to

iptables -t nat -A POSTROUTING -p tcp –sport 443 –dst 192.168.1.66 -o ens192 -j MASQUERADE

futurama ★★★★★
()
Последнее исправление: futurama (всего исправлений: 1)
Ответ на: комментарий от Anoxemian

Да это был танец с бубном

возможно пакеты исходящие из VPN считаются локальными и надо СНАТ пихать в ИНПУТ

iptables -t nat -A INPUT -p tcp –sport 443 –dst 192.168.1.66 -j SNAT –to-source 192.168.1.65

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

Нет, но присобачивать хук ради.. только ради... смысла ровно ноль.

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

СПАСИБО! Всё заработало как надо.

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

и скорость - тоже. вообще это написано в докции:

MASQUERADE incurs extra overhead and is slower than SNAT because each time MASQUERADE target gets hit by a packet, it has to check for the IP address to use.

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

причём тут кофеварки? это в любом случае много доп. тактов на любой архитектуре:

newsrc = inet_select_addr(out, nh, RT_SCOPE_UNIVERSE);

транслируется больше чем 20 строчек кода только в самой подпрограмме

  • вызов и возврат с параметрами на стеке (CALL+RET)
mumpster ★★★★★
()
Ответ на: комментарий от mumpster

Ну да, ну да... мы все умрем и всё такое.

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