Коллеги, подскажите у кого есть опыт успешного решения такой задачи? Суть в следующем,
есть шлюз, за ним располагается локалка. Необходимо выполнять проброс порта рдп с машинкок за шлюзом в зависимости от сертификата (ключа). Смысл в том, чтобы не городить кучу пробросов а раздавать с одного сервиса, ориентируясь по предоставленному ключу, либо иного критерия аутентификации. С первого взгляда на ум приходит ssh tunnel, но он имеет тенденцию отламываться (особенно при gprs подключении), stunnel, vpn.
VPN использовать категорически не хочется, так как он блокируется мелкими провайдерами и часто закрыт в гостиницах и других публичных точках. Stunnel настроить для выполнения "избирательного" проброса не удалось. Какие еще могут быть пути решения. (TeamViewer не предлагать)
>[оверквотинг удален]
> есть шлюз, за ним располагается локалка. Необходимо выполнять проброс порта рдп с
> машинкок за шлюзом в зависимости от сертификата (ключа). Смысл в том,
> чтобы не городить кучу пробросов а раздавать с одного сервиса, ориентируясь
> по предоставленному ключу, либо иного критерия аутентификации. С первого взгляда на
> ум приходит ssh tunnel, но он имеет тенденцию отламываться (особенно при
> gprs подключении), stunnel, vpn.
> VPN использовать категорически не хочется, так как он блокируется мелкими провайдерами
> и часто закрыт в гостиницах и других публичных точках. Stunnel настроить
> для выполнения "избирательного" проброса не удалось. Какие еще могут быть пути
> решения. (TeamViewer не предлагать)майкрософту майкрософтово:
> майкрософту майкрософтово:
> http://technet.microsoft.com/en-us/library/cc731150.aspxСпасибо за ответ!
В целом согласен, но хочется рассмотреть задачу шире, и, желательно, без майкрософта.
>> майкрософту майкрософтово:
>> http://technet.microsoft.com/en-us/library/cc731150.aspx
> Спасибо за ответ!
> В целом согласен, но хочется рассмотреть задачу шире, и, желательно, без майкрософта.ставим, к примеру, OpenVPN, в зависимости от сертификата - выдаем клиенту привязанный к сертификату _его_ IP. Дальше делаем iptables DNAT... Но вы от этого как-то пытаетесь уйти, так что я не знаю, что советовать. Попробуйте обрисовать вашу задачу пошире.
> ставим, к примеру, OpenVPN, в зависимости от сертификата - выдаем клиенту привязанный
> к сертификату _его_ IP. Дальше делаем iptables DNAT... Но вы от
> этого как-то пытаетесь уйти, так что я не знаю, что советовать.
> Попробуйте обрисовать вашу задачу пошире.Наиболее близкое к общему описанию задачи будет звучать так: балансировка (разброс) входящих соединений с распределением сессий по хостам, в зависимости от идентификационных данных.
Если не умничать, то в идеале это выглядит так
Пользователь цепляется на порт шлюза, который слушает некая софтина. Происходит некая авторизация пользователя (это может быть сертификат, логин/пароль, прочее). После чего, в зависимости от предоставленных данных, траффик перенаправляется на машинку за шлюзом на определенный порт. Наиболее перспективным видится путь с сертификатами и ssl туннеллем, клиент предоставляет public.key, на сервере поочередно перебираются private.key, когда обнаруживается совпадение пары public-private траффик дешифруется и перенаправляется на перопределенный порт/хост
> Пользователь цепляется на порт шлюза, который слушает некая софтина. Происходит некая авторизация
> пользователя (это может быть сертификат, логин/пароль, прочее).Вы уже осмыслили, как это будет выглядеть (происходить) на клиенте?
>> Пользователь цепляется на порт шлюза, который слушает некая софтина. Происходит некая авторизация
>> пользователя (это может быть сертификат, логин/пароль, прочее).
> Вы уже осмыслили, как это будет выглядеть (происходить) на клиенте?Опять же в идеале примерно таким образом:
На клиенте установлена некая софтина, способная создавать ssl туннель, шифруя траффик заранее предоставленным public ключом из пары public-private. Для каждого из клиентов свой набор пар ключей. Эта софтина, будучи запущенной, цепляется на порт шлюза и устанавливает ssl туннель. Конечное клиенское приложение цепляется по обратной петле на порт, слушаемый софтиной и весь траффик клиенского приложения убегает в туннель, расшифровывается на сервере и передается на зашлюзный комп. В общем случае так умеет работать stunnel, ssh, не хватает только серверного приложения, способного работать по вышеуказанной схеме. Самым дубовым образом это можно реализовать на уровне ssh туннеля, остановливает только нестабильность его работы.
>[оверквотинг удален]
> На клиенте установлена некая софтина, способная создавать ssl туннель, шифруя траффик заранее
> предоставленным public ключом из пары public-private. Для каждого из клиентов свой
> набор пар ключей. Эта софтина, будучи запущенной, цепляется на порт шлюза
> и устанавливает ssl туннель. Конечное клиенское приложение цепляется по обратной петле
> на порт, слушаемый софтиной и весь траффик клиенского приложения убегает в
> туннель, расшифровывается на сервере и передается на зашлюзный комп. В общем
> случае так умеет работать stunnel, ssh, не хватает только серверного приложения,
> способного работать по вышеуказанной схеме. Самым дубовым образом это можно реализовать
> на уровне ssh туннеля, остановливает только нестабильность его работы.
>>ставим, к примеру, OpenVPN, в зависимости от сертификата - выдаем клиенту привязанный к >>сертификату _его_ IP. Дальше делаем iptables DNAT..
>[оверквотинг удален]
>> На клиенте установлена некая софтина, способная создавать ssl туннель, шифруя траффик заранее
>> предоставленным public ключом из пары public-private. Для каждого из клиентов свой
>> набор пар ключей. Эта софтина, будучи запущенной, цепляется на порт шлюза
>> и устанавливает ssl туннель. Конечное клиенское приложение цепляется по обратной петле
>> на порт, слушаемый софтиной и весь траффик клиенского приложения убегает в
>> туннель, расшифровывается на сервере и передается на зашлюзный комп. В общем
>> случае так умеет работать stunnel, ssh, не хватает только серверного приложения,
>> способного работать по вышеуказанной схеме. Самым дубовым образом это можно реализовать
>> на уровне ssh туннеля, остановливает только нестабильность его работы.
>>>ставим, к примеру, OpenVPN, в зависимости от сертификата - выдаем клиенту привязанный к >>сертификату _его_ IP. Дальше делаем iptables DNAT..C впн-ом всё очевидно, да. Можно вообще не заморачиваться с DNAT, выдать ему айпишник из той же подсети, где требуемый комп живет и пусть ходит напрямую. С впн-ом проблемы другого толка, подразумевается мобильность пользователей, т.е. подключение из гостиниц, публичных вай-фай точек и тут начинаются проблемы. Режут этот самый впн часто, самым злым образом. У ssl туннелья шансов пробраться больше (ведь не станут же они блокировать https).
> C впн-ом всё очевидно, да. Можно вообще не заморачиваться с DNAT, выдать
> ему айпишник из той же подсети, где требуемый комп живет и
> пусть ходит напрямую. С впн-ом проблемы другого толка, подразумевается мобильность пользователей,
> т.е. подключение из гостиниц, публичных вай-фай точек и тут начинаются проблемы.
> Режут этот самый впн часто, самым злым образом. У ssl туннелья
> шансов пробраться больше (ведь не станут же они блокировать https).Я не понял, вы уже опробовали OpenVPN, и говорите про проблемы в его использовании?
Эта тема уже начинает напоминать переливание воды из пустого в порожнее.
>> C впн-ом всё очевидно, да. Можно вообще не заморачиваться с DNAT, выдать
>> ему айпишник из той же подсети, где требуемый комп живет и
>> пусть ходит напрямую. С впн-ом проблемы другого толка, подразумевается мобильность пользователей,
>> т.е. подключение из гостиниц, публичных вай-фай точек и тут начинаются проблемы.
>> Режут этот самый впн часто, самым злым образом. У ssl туннелья
>> шансов пробраться больше (ведь не станут же они блокировать https).
> Я не понял, вы уже опробовали OpenVPN, и говорите про проблемы в
> его использовании?
> Эта тема уже начинает напоминать переливание воды из пустого в порожнее.Нет, сейчас как раз этим занимаюсь. По-результатам отпишусь. Спасибо!
>[оверквотинг удален]
>> На клиенте установлена некая софтина, способная создавать ssl туннель, шифруя траффик заранее
>> предоставленным public ключом из пары public-private. Для каждого из клиентов свой
>> набор пар ключей. Эта софтина, будучи запущенной, цепляется на порт шлюза
>> и устанавливает ssl туннель. Конечное клиенское приложение цепляется по обратной петле
>> на порт, слушаемый софтиной и весь траффик клиенского приложения убегает в
>> туннель, расшифровывается на сервере и передается на зашлюзный комп. В общем
>> случае так умеет работать stunnel, ssh, не хватает только серверного приложения,
>> способного работать по вышеуказанной схеме. Самым дубовым образом это можно реализовать
>> на уровне ssh туннеля, остановливает только нестабильность его работы.
>>>ставим, к примеру, OpenVPN, в зависимости от сертификата - выдаем клиенту привязанный к >>сертификату _его_ IP. Дальше делаем iptables DNAT..Или я неправильно понял ваш ответ?
>[оверквотинг удален]
>> На клиенте установлена некая софтина, способная создавать ssl туннель, шифруя траффик заранее
>> предоставленным public ключом из пары public-private. Для каждого из клиентов свой
>> набор пар ключей. Эта софтина, будучи запущенной, цепляется на порт шлюза
>> и устанавливает ssl туннель. Конечное клиенское приложение цепляется по обратной петле
>> на порт, слушаемый софтиной и весь траффик клиенского приложения убегает в
>> туннель, расшифровывается на сервере и передается на зашлюзный комп. В общем
>> случае так умеет работать stunnel, ssh, не хватает только серверного приложения,
>> способного работать по вышеуказанной схеме. Самым дубовым образом это можно реализовать
>> на уровне ssh туннеля, остановливает только нестабильность его работы.
>>>ставим, к примеру, OpenVPN, в зависимости от сертификата - выдаем клиенту привязанный к >>сертификату _его_ IP. Дальше делаем iptables DNAT..Можно пойти вообще третьим путем, нарисовать вэб морду с авторизацией, авторизацию прошел, вывод формочки с текстом "вставьте в пункт "выполнить" mstsc IP_addr:port", а на уровне файерволла открывается некий порт для этого айпишника с пробросом на dnat. Но это уже антисексуальным извращением попахивает
>> майкрософту майкрософтово:
>> http://technet.microsoft.com/en-us/library/cc731150.aspx
> Спасибо за ответ!
> В целом согласен, но хочется рассмотреть задачу шире, и, желательно, без майкрософта.Вероятно, применительно к rdp можно попробовать использовать haproxy. Опять же вопрос к студии, кто юзал, что подскажете?
ssh с авторизацией по ключу а потом ssh port forward на ip/port.
Как уже раньше предоложили:
VPN (OpenVPN или strоngSWAN) с выдачей клиенту индивидуального IP, определяемого по предъявляемому клиентом сертификату (фактически по dn в сертификате).> VPN использовать категорически не хочется, так как он блокируется мелкими провайдерами
> и часто закрыт в гостиницах и других публичных точках.Если под блокировкой вы подразумеваете закрытие портов, то можно же и VPN использовать на нестандартных портах.
C IPSec это сложнее (не помню есть ли настройка портов, например для NAT-Traversal, или толь ко стандартый UDP/4500).
C OpenVPN в этом смысле не должно быть проблем - нужен только один порт на ваш выбор.