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

На всякий случай оставлю это здесь.
И еще это.

Хотел это покопать. Но время, по моим оценкам 2-3 месяца. Если согласны оплачивать то будет под ключ. В принципе справится сервер типа 360g8 стандартная веб морда, транк от камер, интеграция с астериксом и всем чем захотите. По российским номерам совпадение примерно 92%

RusGuard, ProxWay, и там и там есть модули для таких дел + API

Посоветую не учиться по курсам.

Выше сказали почему не стоит. Я скажу почему стоит и когда. Обычно это внутренние системы где прибито гвоздями требование IE6 не удивляйтесь такой версии есть. В других случаях не используйте

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

Сервер в Европе - промежуточный VPN сервер, к которому будет идти VPN из офиса (openvpn\wiregurd c каждого моноблока или общий VPN на выходе из офиса), от которого будет идти VPN к конечному серверу. Никакого NAT, только маршруты и в подключении RDP будет адрес сервера из серой подсети.
И да - будут подлагивания.

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

К баранам.

Задача сводится к обычному нату, который меняет в пакете пришедшем на порт 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 и отправляет пакет туда, откуда он пришел.

Я уже лет 5 занимаюсь подобной работой для бухгалтерий и могу сказать, что у вы много чего делаете не так
1) сервер в РФ сразу идёт лесом, т.к. любой обэп или отдел к сможет легко нагнуть вашего хостера. Сервер должен находиться в Европе. Причем некоторые типа хэцнера тоже сотрудничают с нашими и просто могут закрыть вам доступ.
2) скорее всего ваш сервер сидит в интернете что называется голой опой(порт rdp открыт). И даже если вы измените порт рдп, то он все равно просканиваться ботами и у вас постоянно будет идти подбор паролей. В качестве временного решения можно получить на работе постоянный ip у провайдера и настроить фаерволл сервера на подключение по rdp с этого ip. Но это отменит возможность подключения с разных мест... Best practics - это использование варитуальных машин на сервере, которые будут сидеть за виртуальным роутером. Далее делается шифрованный туннель между роутером в вашем офисе и виртуальным роутером и подключаются люди по рдп уже внутри этого туннеля по серым ip-адресам. Я предпочитаю использовать оборудование mikrotik. Виртуалки также удобны тем, что их легко можно бэкапить, а также переносить на другие сервера в случае расширения.

Я думаю что если параноить то по полной, точнее нужно обезопасить себя на всех участках соединения. Но и чтобы решение не слишком мудреное было и без глюков.
Предлагаю следующее:
на арендуемом сервере ставим mikrotik chr, или простой линух и port knocking там настраиваем по аналогии статьи про port knocking, далее пробрасываем там желательно нестандартный rdp порт на ip в вашем дата центре, а в сетевых настройках в дата центре указываем принимать соединения только с ip арендуемого сервера на выбранный нами порт и пробрасываем на наш RDP сервер.
конечная схема выглядит так:
Клиент из офиса стучится по port knocking на арендуемый сервер, ему открывается определенный порт для RDP, потом этот порт прокидывается на ваш сервер в дата центре, устанавливается соединение, клиент спокойно работает, а порт на арендуемом сервере закрывается (кроме установленных соединений).