https://opennet.dev/openforum/vsluhforumID1/94964.html Коллеги, подскажите у кого есть опыт успешного решения такой задачи? Суть в следующем,<br>есть шлюз, за ним располагается локалка. Необходимо выполнять проброс порта рдп с машинкок за шлюзом в зависимости от сертификата (ключа). Смысл в том, чтобы не городить кучу пробросов а раздавать с одного сервиса, ориентируясь по предоставленному ключу, либо иного критерия аутентификации. С первого взгляда на ум приходит ssh tunnel, но он имеет тенденцию отламываться (особенно при gprs подключении), stunnel, vpn.<br>VPN использовать категорически не хочется, так как он блокируется мелкими провайдерами и часто закрыт в гостиницах и других публичных точках. Stunnel настроить для выполнения "избирательного" проброса не удалось. Какие еще могут быть пути решения. (TeamViewer не предлагать)<br> https://opennet.dev/openforum/vsluhforumID1/94964.html#15 Sun, 01 Sep 2013 14:36:43 GMT Как уже раньше предоложили:<br>VPN (OpenVPN или strоngSWAN) с выдачей клиенту индивидуального IP, определяемого по предъявляемому клиентом сертификату (фактически по dn в сертификате).<br><br>&gt; VPN использовать категорически не хочется, так как он блокируется мелкими провайдерами <br>&gt; и часто закрыт в гостиницах и других публичных точках.<br><br>Если под блокировкой вы подразумеваете закрытие портов, то можно же и VPN использовать на нестандартных портах.<br>C IPSec это сложнее (не помню есть ли настройка портов, например для NAT-Traversal, или толь ко стандартый UDP/4500).<br>C OpenVPN в этом смысле не должно быть проблем - нужен только один порт на ваш выбор.<br><br> https://opennet.dev/openforum/vsluhforumID1/94964.html#14 Fri, 30 Aug 2013 14:45:31 GMT ssh с авторизацией по ключу а потом ssh port forward на ip/port.<br> https://opennet.dev/openforum/vsluhforumID1/94964.html#13 Fri, 30 Aug 2013 07:03:20 GMT &gt;&gt; C впн-ом всё очевидно, да. Можно вообще не заморачиваться с DNAT, выдать <br>&gt;&gt; ему айпишник из той же подсети, где требуемый комп живет и <br>&gt;&gt; пусть ходит напрямую. С впн-ом проблемы другого толка, подразумевается мобильность пользователей, <br>&gt;&gt; т.е. подключение из гостиниц, публичных вай-фай точек и тут начинаются проблемы.<br>&gt;&gt; Режут этот самый впн часто, самым злым образом. У ssl туннелья <br>&gt;&gt; шансов пробраться больше (ведь не станут же они блокировать https).<br>&gt; Я не понял, вы уже опробовали OpenVPN, и говорите про проблемы в <br>&gt; его использовании?<br>&gt; Эта тема уже начинает напоминать переливание воды из пустого в порожнее.<br><br>Нет, сейчас как раз этим занимаюсь. По-результатам отпишусь. Спасибо!<br> https://opennet.dev/openforum/vsluhforumID1/94964.html#12 Fri, 30 Aug 2013 07:00:16 GMT <br>&gt; C впн-ом всё очевидно, да. Можно вообще не заморачиваться с DNAT, выдать <br>&gt; ему айпишник из той же подсети, где требуемый комп живет и <br>&gt; пусть ходит напрямую. С впн-ом проблемы другого толка, подразумевается мобильность пользователей, <br>&gt; т.е. подключение из гостиниц, публичных вай-фай точек и тут начинаются проблемы. <br>&gt; Режут этот самый впн часто, самым злым образом. У ssl туннелья <br>&gt; шансов пробраться больше (ведь не станут же они блокировать https).<br><br>Я не понял, вы уже опробовали OpenVPN, и говорите про проблемы в его использовании?<br>Эта тема уже начинает напоминать переливание воды из пустого в порожнее.<br><br><br> https://opennet.dev/openforum/vsluhforumID1/94964.html#11 Fri, 30 Aug 2013 06:52:30 GMT &gt;[оверквотинг удален]<br>&gt;&gt; На клиенте установлена некая софтина, способная создавать ssl туннель, шифруя траффик заранее <br>&gt;&gt; предоставленным public ключом из пары public-private. Для каждого из клиентов свой <br>&gt;&gt; набор пар ключей. Эта софтина, будучи запущенной, цепляется на порт шлюза <br>&gt;&gt; и устанавливает ssl туннель. Конечное клиенское приложение цепляется по обратной петле <br>&gt;&gt; на порт, слушаемый софтиной и весь траффик клиенского приложения убегает в <br>&gt;&gt; туннель, расшифровывается на сервере и передается на зашлюзный комп. В общем <br>&gt;&gt; случае так умеет работать stunnel, ssh, не хватает только серверного приложения, <br>&gt;&gt; способного работать по вышеуказанной схеме. Самым дубовым образом это можно реализовать <br>&gt;&gt; на уровне ssh туннеля, остановливает только нестабильность его работы.<br>&gt;&gt;&gt;ставим, к примеру, OpenVPN, в зависимости от сертификата - выдаем клиенту привязанный к &gt;&gt;сертификату _его_ IP. Дальше делаем iptables DNAT..<br><br>Можно пойти вообще третьим путем, нарисовать вэб морду с авторизацией, авториз https://opennet.dev/openforum/vsluhforumID1/94964.html#10 Fri, 30 Aug 2013 06:42:47 GMT &gt;[оверквотинг удален]<br>&gt;&gt; На клиенте установлена некая софтина, способная создавать ssl туннель, шифруя траффик заранее <br>&gt;&gt; предоставленным public ключом из пары public-private. Для каждого из клиентов свой <br>&gt;&gt; набор пар ключей. Эта софтина, будучи запущенной, цепляется на порт шлюза <br>&gt;&gt; и устанавливает ssl туннель. Конечное клиенское приложение цепляется по обратной петле <br>&gt;&gt; на порт, слушаемый софтиной и весь траффик клиенского приложения убегает в <br>&gt;&gt; туннель, расшифровывается на сервере и передается на зашлюзный комп. В общем <br>&gt;&gt; случае так умеет работать stunnel, ssh, не хватает только серверного приложения, <br>&gt;&gt; способного работать по вышеуказанной схеме. Самым дубовым образом это можно реализовать <br>&gt;&gt; на уровне ssh туннеля, остановливает только нестабильность его работы.<br>&gt;&gt;&gt;ставим, к примеру, OpenVPN, в зависимости от сертификата - выдаем клиенту привязанный к &gt;&gt;сертификату _его_ IP. Дальше делаем iptables DNAT..<br><br>Или я неправильно понял ваш ответ?<br> https://opennet.dev/openforum/vsluhforumID1/94964.html#9 Fri, 30 Aug 2013 06:39:27 GMT &gt;[оверквотинг удален]<br>&gt;&gt; На клиенте установлена некая софтина, способная создавать ssl туннель, шифруя траффик заранее <br>&gt;&gt; предоставленным public ключом из пары public-private. Для каждого из клиентов свой <br>&gt;&gt; набор пар ключей. Эта софтина, будучи запущенной, цепляется на порт шлюза <br>&gt;&gt; и устанавливает ssl туннель. Конечное клиенское приложение цепляется по обратной петле <br>&gt;&gt; на порт, слушаемый софтиной и весь траффик клиенского приложения убегает в <br>&gt;&gt; туннель, расшифровывается на сервере и передается на зашлюзный комп. В общем <br>&gt;&gt; случае так умеет работать stunnel, ssh, не хватает только серверного приложения, <br>&gt;&gt; способного работать по вышеуказанной схеме. Самым дубовым образом это можно реализовать <br>&gt;&gt; на уровне ssh туннеля, остановливает только нестабильность его работы.<br>&gt;&gt;&gt;ставим, к примеру, OpenVPN, в зависимости от сертификата - выдаем клиенту привязанный к &gt;&gt;сертификату _его_ IP. Дальше делаем iptables DNAT..<br><br>C впн-ом всё очевидно, да. Можно вообще не заморачиваться с DNAT, выдать ему а https://opennet.dev/openforum/vsluhforumID1/94964.html#8 Fri, 30 Aug 2013 06:30:44 GMT <br>&gt;[оверквотинг удален]<br>&gt; На клиенте установлена некая софтина, способная создавать ssl туннель, шифруя траффик заранее <br>&gt; предоставленным public ключом из пары public-private. Для каждого из клиентов свой <br>&gt; набор пар ключей. Эта софтина, будучи запущенной, цепляется на порт шлюза <br>&gt; и устанавливает ssl туннель. Конечное клиенское приложение цепляется по обратной петле <br>&gt; на порт, слушаемый софтиной и весь траффик клиенского приложения убегает в <br>&gt; туннель, расшифровывается на сервере и передается на зашлюзный комп. В общем <br>&gt; случае так умеет работать stunnel, ssh, не хватает только серверного приложения, <br>&gt; способного работать по вышеуказанной схеме. Самым дубовым образом это можно реализовать <br>&gt; на уровне ssh туннеля, остановливает только нестабильность его работы.<br>&gt;&gt;ставим, к примеру, OpenVPN, в зависимости от сертификата - выдаем клиенту привязанный к &gt;&gt;сертификату _его_ IP. Дальше делаем iptables DNAT..<br><br> https://opennet.dev/openforum/vsluhforumID1/94964.html#7 Fri, 30 Aug 2013 06:24:12 GMT &gt;&gt; Пользователь цепляется на порт шлюза, который слушает некая софтина. Происходит некая авторизация <br>&gt;&gt; пользователя (это может быть сертификат, логин/пароль, прочее).<br>&gt; Вы уже осмыслили, как это будет выглядеть (происходить) на клиенте?<br><br>Опять же в идеале примерно таким образом:<br>На клиенте установлена некая софтина, способная создавать ssl туннель, шифруя траффик заранее предоставленным public ключом из пары public-private. Для каждого из клиентов свой набор пар ключей. Эта софтина, будучи запущенной, цепляется на порт шлюза и устанавливает ssl туннель. Конечное клиенское приложение цепляется по обратной петле на порт, слушаемый софтиной и весь траффик клиенского приложения убегает в туннель, расшифровывается на сервере и передается на зашлюзный комп. В общем случае так умеет работать stunnel, ssh, не хватает только серверного приложения, способного работать по вышеуказанной схеме. Самым дубовым образом это можно реализовать на уровне ssh туннеля, остановливает только нестабильность его работы.<br>