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

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

В продолжение вопроса о скрытии 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 минут работы...?

Заранее спасибо, за любой результат.
  • Вопрос задан
  • 669 просмотров
Решения вопроса 2
@domres Автор вопроса
Друзья спасибо всем за советы и мнения! Очень рад что тема нашла отклик. Надеюсь все написанное пригодится не только мне.

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

Решил не возиться пока с 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).

Всем спасибо!
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 2
CityCat4
@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 и отправляет пакет туда, откуда он пришел.
Ответ написан
Комментировать
@HomeMan
Никита, не той дорогой идешь. Ответ в первом твоем вопросе.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы