Как на CentOs 7 сделать «проброс» порта из интернета на другой сервер интернета (аля шлюз)?

Question

[Игорь Захаров]

Добрый вечер друзья!

В продолжение вопроса о скрытии RDP сервера я пытаюсь реализовать то, что мне посоветовали знающие, но у меня знаний не хватило, так как я с linux системами не знаком от слова совсем. :(

Кратко о задаче чтобы Вы понимали что нужно сделать и зачем, но предыдущий вопрос не открывали:
Есть RDP сервер, расположенный в РФ. Нужно, чтобы на клиентах IP подключения к RDP серверу был другим, желательно в недалекой европейской стране. Иными словами нам нужен сервер-посредник, который принимал бы подключения по 3389 порту, перенаправлял TCP/UDP на реальный IP сервера на тот же порт 3389, сохраняя реальный IP в тайне от юзеров и любопытствующих субъектов.

Мне уже популярно объяснили что это бредятина, шпиономания и вообще колхоз и тупость, но задача поставлена, а я туплю, но пытаюсь выполнить пожелание руководства в ключе "любой каприз за Ваши деньги".

Попытка решения задачи, которая у меня не прошла:

Взял VDS 1x2.2ГГц, 1Гб RAM, 1 IP. Установлена CentOs 7.6.1810. Пробовал ковырять оба предложенных варианта: haproxy и отключение firewalld с включением iptables. Конфиги для меня как иероглифы.

Если у кого-то есть время и желание научить дурака науке, опишите пожалуйста процесс реализации этого (по мнению экспертов предыдущего вопроса) пустякового дела на 10 минут работы...?

Заранее спасибо, за любой результат.

Comments

[vreitech]

мне интересно, а вы уже придумали, что будете делать с тем, что, подключившись к RDP серверу по RDP и зайдя в свойства сетевого адаптера вы увидите его реальный адрес, а не адрес сервера-посредника? или это в вашем случае не важно?

Answer 1

[Valentin Barbolin]

Ходи сюды.

Спрятать RDP сервер... а как?

Comments

[Игорь Захаров]

так точно, но либо я что-то не так делаю, либо... да не либо, а точно не так что-то делаю...

Куда и как это запихивать? Передо мной открыта консоль сервера по SSH, я вырубил firewalld и установил iptables...

[Valentin Barbolin]

покажи вывод
sudo iptables-save

[Игорь Захаров]

Andrey Barbolin, -bash-4.2# sudo iptables-save
# Generated by iptables-save v1.4.21 on Thu Jun 25 22:35:06 2020
*filter
:INPUT ACCEPT [26:2297]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [26:3805]
COMMIT
# Completed on Thu Jun 25 22:35:06 2020

[Valentin Barbolin]

Заходишь под root
sudo -s

Копируешь это в блокнот, правишь под себя, потому копируешь в вставляешь в консоль.

# Адрес твоего RDP сервера
RDP_IP='192.43.76.78'
## Адрес твоего VPS
WAN_IP='54.23.45.43'
## Имя интерфейса на VPS, можно посмотреть через команду ip ad
WAN_INTERFACE=ens33
SRC_PORT_FORWARD=3389
DST_PORT_FORWARD=3389
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A PREROUTING -i $WAN_INTERFACE -p tcp  --dport $SRC_PORT_FORWARD -j DNAT --to-destination $RDP_IP
iptables -t nat -A POSTROUTING -d $RDP_IP -p tcp  --dport $DST_PORT_FORWARD -j SNAT --to-source $WAN_IP

[Игорь Захаров]

Andrey Barbolin, спасибо, сейчас попробую...

[Игорь Захаров]

Andrey Barbolin, на строчке iptables -t nat -A PREROUTING -i $WAN_INTERFACE -p tcp --dport $SRC_PORT_FORWARD -j DNAT --to-destination $RDP_IP
консоль выдала bad argument 'tcp'

[Valentin Barbolin]

вывод команды

echo $WAN_INTERFACE

[Игорь Захаров]

Andrey Barbolin, eth0

[Valentin Barbolin]

а тут?

ip ad | grep state

[Игорь Захаров]

Andrey Barbolin,

1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
2: eth0: mtu 1500 qdisc mq state UP group default qlen 1000

[Valentin Barbolin]

Попробуй вот эти строки поменять

WAN_INTERFACE='eth0'
SRC_PORT_FORWARD='3389'
DST_PORT_FORWARD='3389'

[Игорь Захаров]

Andrey Barbolin, нет, к сожалению ничего не выходит. iptables установлено, вошел под root... команды вставляю в консоль - ничего. Порт закрыт. Правила не вписываются.. Видимо я криворук. Извините что загрузил (

[Valentin Barbolin]

Тяжело понять в чем именно проблема не имея доступа к консоли. Если есть выбор, попробуй поставить debian/ubuntu.

[Alexander]

Никита Шинкевич, firewall точно отключен? Посмотрите, действительно открыты ли эти порты

Answer 2

[Игорь Захаров]

Друзья спасибо всем за советы и мнения! Очень рад что тема нашла отклик. Надеюсь все написанное пригодится не только мне.

Самостоятельно пришел к следующему решению:

Решил не возиться пока с Linux ввиду недостатка опыта работы с оным, а взял в Финляндии виртуалку с Windows Server 2016 за 3$ в мес. На арендованном забугорном сервере поднята SoftEther VPN Server с SecureNAT. Виртуальная машина с сервером терминалов, расположенная в РФ коннектится через L2TP VPN к этому серверу. А юзеры терминалов коннетятся к нему же таким же образом через L2TP VPN.

Получилась схема: Клиент RDP через VPN -> Сервер в Финляндии (SoftEtherVPN Server) > VPN до сервера в РФ.

Приятно порадовала скорость подключения, лагов нет, качество согласно индикатору RDP 8.1 хорошее.

Более того, покуда в свойствах VPN подключения российского сервера ставим галочку шлюза удаленной сети, удалось дать пользователям RDP сервера доступ в сеть через тот же Финский сервак. Тепеперь у наших RDP юзеров в офисе на сервере терминалов есть еще и интернет, который так же анонимизирован насколько возможно (финский IP).

Всем спасибо!

Answer 3

[CityCat4]

Задача как задача, вполне себе. Видимо есть основания скрывать тот факт, что целевой сервер в РФ. Бывает. Есть такие -
"...Где с умилением глядят
На заграничные наклейки...
А сало... русское едят! " (С) Михалков С.В. Две подруги.

К баранам.

Задача сводится к обычному нату, который меняет в пакете пришедшем на порт 3389 IP назначения с локального на некий удаленный - после чего ведро ессно этот пакет отправляет в мир на дефолтный шлюз.

Во-первых - всем и каждому, кто впал в затуп и не знает, как проходит пакет по netfilter - рекомендую эту схему. Распечатать и повесить на рабочем месте.

Сначала зададим допущения.
IP сервера = 212.20.5.1 (много-много лет назад это был IP нашего сервера, он реально российский :) )
IP VPS = 170.70.1.1 (взят с потолка)
Политика по умолчанию для filter - ACCEPT (все, что не запрещено - разрешено. Очень опасная политика, вязта только для демонстрации, в жизни так делать нельзя. Мне просто неохота писать дополнительные правила по пропуску трафика)

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]

NAT мы выполняем в цепочке prerouting таблицы nat (она идет до filter). Сюда пакет попадает сразу после mangle prerouting.

*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A PREROUTING -p tcp --dport 3389 -d 170.70.1.1 -j DNAT --to-destination 212.20.5.1

Читается "если поступил пакет по протоколу tcp на порт 3389 на IP 170.70.1.1, то применить действие DNAT, заменив IP назначения на 212.20.5.1. Правило поместить в цепочку prerouting".

Что теперь? А теперь, поскольку мы поменяли IP назначения и он теперь не локальный - ведро считает, что пакет нужно отправить (routing decision на схеме) - в цепочку forward. Сначала mangle forward, потом filter forward (это и есть основная таблица, которую обычно и зовут файрволлом, мы в ней пропускаем все).

Потом mangle postrouting и nat postrouting. В nat postrouting нам нужно сделать небольшой камуфляж. В пакете IP назначения 212.20.5.1 - но IP источника - тот IP, с которого пакет пришел на VPS. Это нам не нужно и потому что задача - его скрыть и потому что при попадании пакета на 212.20.5.1 - он ответит ессно на этот IP. Поэтому выполняем следующее:

-A POSTROUTING -o eth0 -j SNAT --to-source 170.70.1.1

Читаем "если пакет уходит через интерфейс eth0, то применить действие SNAT и заменить IP источника на 170.70.1.1"
Это стандартное правило NAT, оно присутствует всегда, если VPS является NAT хоть для чего-нибудь.

Все. Пакет на 212.20.5.1 уходит от IP 170.70.1.1, тот отвечает по IP источника, VPS видит, что был NAT и отправляет пакет туда, откуда он пришел.

Answer 4

[Евгений]

Никита, не той дорогой идешь. Ответ в первом твоем вопросе.