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

Iptables - проброс порта через VPN сойденение в локальною сеть

 , ,


0

1

Всем доброго времени суток! В общем... Появилась довольно странная и нестандартная задача ясного решения которой в интернете я не нашол... Есть локальная подсеть 10.0.190.0\24 в которой находится VM 10.0.190.235 у которой есть 2 дополнительных ip [.190.236, .190.237] и на которой установлен OpenConnect (аналог Cisco AnyConnect - короче VPN клиент) через него есть доступ к 3 серверам (10.1.2.25, 10.1.3.100, 10.1.3.110) по порту 3389(RDP). Задача состоит в том чтобы пробросить порты через клиентское VPN подключение в локальною подсеть 10.0.190.0\24 через машинку 10.0.190.235 таким образом, чтобы сервера (10.1.2.25, 10.1.3.100, 10.1.3.110) думали что все подключения исходят от выданного VPN сервером клиенту ip-адреса... щас попробую изобразить эту хрень схематически...

                VM:[enp0s3]   10.0.190.235:3389 |   |      [tun0]      | < 10.1.2.25:3389
10.0.190.0\24 >   :[enp0s3:0] 10.0.190.236:3389 |NAT| VPN - connection | < 10.1.3.100:3389
                  :[enp0s3:1] 10.0.190.237:3389 |   |   (dinamic ip)   | < 10.1.3.110:3389

довольно странная и нестандартная задача

По-моему это совершенно стандартная задача: SNAT/MASQUERADE+ip-forwarding

SNAT/MASQUERADE+ip-forwarding надо сделать в виртуалке, а на своей машине добавить маршурт в 10.1.2 и 10.1.3 через 10.0.190.235

или я чего-то не понял?

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

Боюсь, вы меня неправильно поняли... Нужно сделать так чтобы Юзеры что находящиеся в подсети 10.0.190.0\24 Открыв «Подключение к удаленному рабочему столу» и подключившись к 10.0.190.235:3389 попадали скажем на сервер 10.1.2.25:3389 «Прозрачно!» - то есть без каких либо маршрутов на клиентских машинах через 10.0.190.235

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

Боюсь такая подмена может не работать ввиду встроенной в винду криптографии, которая обнаружит подмену. Если я не ошибаюсь.

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

Боюсь такая подмена может не работать ввиду встроенной в винду криптографии, которая обнаружит подмену. Если я не ошибаюсь.

Ничего такого это же просто проброс порта за NAT... разница лишь в том что не из локальной сети в интернет а из vpn-соединения в локальною сеть.

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

Маршрут-то зачем? DNAT
А в остальном все верно «SNAT/MASQUERADE+ip-forwarding»

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

Я бы тогда не стал сношаться с DNAT-ом, а просто запустил xinetd c redirect

service qweqweqwe
{
    port            = 3389
    bind            = 10.0.190.236
    type            = UNLISTED
    disable         = no
    socket_type     = stream
    protocol        = tcp
    wait            = no
    user            = nobody
    redirect        = 10.1.2.25 3389
    flags           = IPv4
}

и так далее для остальных

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

Я бы тогда не стал сношаться с DNAT-ом,

Одна строка, это конечно очень сложно.

а просто запустил xinetd

Которого может и не быть.

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

Если я ничего не путаю, то главная проблема у тебя в том что твой 10.1.2.25:3389 пытается отвечать не в 10.0.190.0\24, а 10.0.190.235 И твоя 10.0.190.235 просто не знает что делать с ответным пакетом. Тебе и натить и маршрутизировать надо. У подсети где живет 10.1.2.25, 10.0.190.235 должен быть дефолт гетвеем. Хотя может я и чего не понял и ахинею несу.

AfterWork
()

Вообщем... На третий день я таки отчасти смог достичь нужного мне результата... Но только на половину... (работает только 1 интерфейс)

iptables -t nat -A PREROUTING -i enp0s3 -d 10.0.190.235 -p tcp --dport 3389 -j DNAT --to-destination 10.1.2.25:3389
iptables -A FORWARD -i enp0s3 -o tun0 -d 10.1.2.25 -p tcp --dport 3389 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.1.2.25 -p tcp --dport 3389 -j MASQUERADE

Когда я размножаю это правило для остальных интерфейсов сталкиваюсь с проблемой работают только те правила у которых основным интерфейсом указан enp0s3 а дополнительные ip-адреса(интерфейсы) не работают... почему так?

iptables -t nat -A PREROUTING -i enp0s3   -d 10.0.190.235 -p tcp --dport 3389 -j DNAT --to-destination 10.1.2.25:3389
iptables -t nat -A PREROUTING -i enp0s3:0 -d 10.0.190.236 -p tcp --dport 3389 -j DNAT --to-destination 10.1.3.100:3389
iptables -t nat -A PREROUTING -i enp0s3:1 -d 10.0.190.237 -p tcp --dport 3389 -j DNAT --to-destination 10.1.3.110:3389
iptables -A FORWARD -i enp0s3   -o tun0 -d 10.1.2.25  -p tcp --dport 3389 -j ACCEPT
iptables -A FORWARD -i enp0s3:0 -o tun0 -d 10.1.3.100 -p tcp --dport 3389 -j ACCEPT
iptables -A FORWARD -i enp0s3:1 -o tun0 -d 10.1.3.110 -p tcp --dport 3389 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.1.2.25  -p tcp --dport 3389 -j MASQUERADE
iptables -t nat -A POSTROUTING -o tun0 -d 10.1.3.100 -p tcp --dport 3389 -j MASQUERADE
iptables -t nat -A POSTROUTING -o tun0 -d 10.1.3.110 -p tcp --dport 3389 -j MASQUERADE

Я так понял, я создал некий аналог multi-wan с несколькими ip... что мне сделать, чтобы трафик шел через дополнительные ip-адреса тоже? а не только через основной...

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

enp0s3:0 это не интерфейс а алиас. iptables не работает с алиасами, интерфейс у вас enp0s3 вот его и прописывайте, типа:
iptables -t nat -A PREROUTING -i enp0s3 -d 10.0.190.236 -p tcp --dport 3389 -j DNAT --to-destination 10.1.3.100:3389
iptables -t nat -A PREROUTING -i enp0s3 -d 10.0.190.237 -p tcp --dport 3389 -j DNAT --to-destination 10.1.3.110:3389
и т.д.

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

enp0s3:0 это не интерфейс а алиас. iptables не работает с алиасами, интерфейс у вас enp0s3 вот его и прописывайте

Хах... неожыданно... Большое спасибо помогло!

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

Хах... неожыданно...

Скорее вполне ожидаемо. Алиасы это уже скорее устаревшее понятие, было во времена ifconfig, iproute2 обходиться без этих названий, т.е. просто навешиваем доп. адреса на тот же интерфейс.
А iptables (не только он один, тот же tcpdump) в параметрах использует физ. интерфейсы, поэтому и не работало. Вобчем ваша ошибка скорее историческая... :) воспринимать алиас как реальный интерфейс. Набирают что-то типа ifconfig eth0:5 down и удивляются почему все рухнуло :)

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