Как засунуть входящий RDP в GRE



  • Если честно даже не уверен в правильной формулировке темы, поэтому прошу со мной попроще.
    Имеется тунель (GRE) от моей локалки 192.168.х.у до Cisco 111.222.111.222 (это внешний IP другого офиса). GRE tunnel local address 10.100.0.15, remote address 10.100.0.16. С моей локалки RDP до удаленного сервера 12.13.14.15 (это локальный IP сервера 1С) работает, нареканий нет. Имеется пара отделов и человек за пределами моей локалки, но им надо дать доступ по RDP на 12.13.14.15. Попробовал подключение на мой внешний IP (85.85.85.85) и дальше через NAT на 12.13.14.15, но увы. Прокси сейчас нет, в файрволе все разрешено. Проброс RDP на локальные компы работает, но хочу минуя промежуточные подключения подключить пользователей к 1С (12.13.14.15). Прошу разъяснить логику такого подключения (возможно ли оно вообще) и помощи в настройке.



  • @ZABor:

    Имеется пара отделов и человек за пределами моей локалки, но им надо дать доступ по RDP на 12.13.14.15.

    Это внешние пользователи?

    Можно конечно мапингом с внешнего порта, но это не секюрно.
    Подумайте над организацией VPN подключений (к примеру OpenVPN) для таких пользователей.



  • Пользователи внешние (за пределами локалки). И мне надо быстро их подключить, а не правильно. Правильно потом, там с сетью еще много вопросов. И собсно в маппинге весь вопрос: куда его направлять? на сервер 1С? а pfsensу как объяснить, что это в туннеле? или как-то иначе (вот тут я логики и не пойму)



  • Да, маппинг WAN на сервер 1С. А "объяснить" - это обеспечить видимость и маршрутизацию пакетов к серверу 1С с интерфейса WAN и обратно.
    То-есть и WAN и 1С должны знать куда слать пакеты.

    Но тут одно НО - ваш 1С может пытаться ответить на публичный адрес WAN не через туннель, а через интернет. Поэтому нужно слать пакеты на 1С от имени локального интерфейса (например LAN).

    Пример
    Удаленный клиент -> WAN PFSense – mapping to 1C --> OPT(10.100.0.15) tunnel -- NAT from any to 1C --> tunnel ---......-->1C


Log in to reply