Доброго времени суток!Есть такая задачка:
обеспечить доступ удаленным клиентам к внутренней сети предприятия. Клиент может работать как на своем ноутбуке, так и на чужом компьютере. Как с настоящего адреса, так и через прокси или натинг. Соответственно должен организовываться тунель поверх https протокола. и последнее, сервер на RHEL, а клиенты, естественно под оффтопиком.Посоветуйте люди добрые, в какую сторону мне копать для решения задачи?
проблема усложнена еще и тем, что после того, как пользователь поработал на чужом компьютере, ничего не должно оставаться. т.е. если и запускался клиент, то он должен автоматически деинсталлироваться, затирая за собой все следы (вдруг пользователь зашел с какого-нибудь интернет кафе). Так же предполагается, что данным сервисом будет пользоваться и высокое рукамиводство, которое любит, чтобы все работало с нажатия на одну кнопочку.
еще один момент. на сервере уже поднят апач на 80 и 443 портах. т.е. 443 порт занят апачем. можно, конечно поднять еще один виртуальный интерфейс, но не хотелось бы... А может быть под апачь есть какая-нибудь приблуда для поднятия vpn? или может быть как-нибудь можно подружить апач с openvpn? но как?
Есть такая задачка:
>обеспечить доступ удаленным клиентам к внутренней сети предприятия. Клиент может
>работать как на своем ноутбуке, так и на чужом компьютере.про "компы в интернет кафе" и чужие компы рекомендую забыть, поскольку чтолибо делать там в принципе не безопасно.
>Как с настоящего адреса, так и через прокси или натинг. Соответственно должен
>организовываться тунель поверх https протокола. и последнее, сервер на RHEL, а клиенты,
>естественно под оффтопиком.Не вижу оснований для "тунель поверх https протокола". Может быть вы хотите сказать "шифрованное соединение" ? Через прокси можно пустить openvpn, но нельзя pptp.
>Посоветуйте люди добрые, в какую сторону мне копать для решения задачи?
>проблема усложнена еще и тем, что после того, как пользователь поработал на чужом
>компьютере, ничего не должно оставаться. т.е. если и запускался клиент, то он должен
>автоматически деинсталлироваться, затирая за собой все следы (вдруг пользователь зашел с
>какого-нибудь интернет кафе).Либо стандартный впн-клиент от винды, либо ничего другого, поскольку опенвпн требует инсталляции драйверов в систему, соответственно админских прав и перезагрузок системы.
>Так же предполагается, что данным сервисом будет
>пользоваться и высокое рукамиводство, которое любит, чтобы все работало с нажатия на
>одну кнопочку.стандартнй впн-клиент от винды.
>еще один момент. на сервере уже поднят апач на 80 и 443
>портах. т.е. 443 порт занят апачем.можно опенвпн подружить с апачью. В доках всё можно найти.
PPTP-сервер 443 и 80 порты не использует.>можно, конечно поднять еще один
>виртуальный интерфейс, но не хотелось бы...а может быть всётаки почитаете что-нибудь ? "виртуальный интерфейс, виртуальный IP-адрес" ?
> А может быть под апачь
>есть какая-нибудь приблуда для поднятия vpn? или может быть как-нибудь можно
>подружить апач с openvpn? но как?ага, а еще можно траффик туннелировать через DNS/ICMP-запросы. Вам промышленно работающую систему подымать или "приблуды"?
-----------
Про W2k8 обчитались ? :)
Ну так что только под Висту и выше.Что делать: Смотреть на VPN клиента он Nortel.
Ява апплет через браузер.
ИМХО, фигней занимаетесь
>Про W2k8 обчитались ? :)
>Ну так что только под Висту и выше.исключено, т.к. у нас на буках только XP.
>Что делать: Смотреть на VPN клиента он Nortel.
Спасибо, гляну.
>Ява апплет через браузер.
>ИМХО, фигней занимаетесьВидимо юзеры не апчитались, а слышали звон, но не знают где он. Но требуют блин...
>Ява апплет через браузер.а вот отсюда можно поподробнее?
>ИМХО, фигней занимаетесь
эх, рад бы не заниматься, но приходится :(
>про "компы в интернет кафе" и чужие компы рекомендую забыть, поскольку чтолибо
>делать там в принципе не безопасно.К сожалению надо чтобы с чужих компов тоже работало.
>стандартнй впн-клиент от винды.
не прокатит т.к. клиент может сидеть за проксей.
>можно опенвпн подружить с апачью. В доках всё можно найти.
>PPTP-сервер 443 и 80 порты не использует.другие порты через проксю не пройдут.
>а может быть всётаки почитаете что-нибудь ? "виртуальный интерфейс, виртуальный IP-адрес" ?
про виртуальные адреса я в курсе, плавали, знаем ;) просто я не хочу ради какого-то впн подключения поднимать еще один адрес. по крайней мере этот вариант будет последним, который я сделаю.
>ага, а еще можно траффик туннелировать через DNS/ICMP-запросы. Вам промышленно работающую систему
>подымать или "приблуды"?можно и dns, но эта возможность может быть закрыта из внутренней сети предприятия. например у нас ни один пользователь не может узнать ip адрес сервера в интернете - не пересылаются запросы на внешний dns.
сервер уже есть, на него надо прикрутить приблуду, которой будут все пользоваться промышленно.
проблема усложняется тем, что чуваку из высшего рукамиводства шепнул какой-то "супер навороченый админ" (не удивлюсь, если этот "супер админ" не знает вааще что такое vpn и иже с ними), что реализация доступа - это как два пальца об асфальт. соответственно теперь мы как специалисты ничего не значим для рукаводства, и у нас только один выход - что-то сделать, либо уволят (кризис блин.)
>проблема усложняется тем, что чуваку из высшего рукамиводства шепнул какой-то "супер навороченый
>админ" (не удивлюсь, если этот "супер админ" не знает вааще что
>такое vpn и иже с ними), что реализация доступа - это
>как два пальца об асфальт. соответственно теперь мы как специалисты ничего
>не значим для рукаводства, и у нас только один выход -
>что-то сделать, либо уволят (кризис блин.)Видимо как раз "супер админ" наоборот знает о технологиях vpn доступа, только забыл сказать что такие решения денег стоят или руководство этот факт опустило.
>[оверквотинг удален]
>поверх https протокола. и последнее, сервер на RHEL, а клиенты, естественно
>под оффтопиком.
>
>Посоветуйте люди добрые, в какую сторону мне копать для решения задачи?
>проблема усложнена еще и тем, что после того, как пользователь поработал на
>чужом компьютере, ничего не должно оставаться. т.е. если и запускался клиент,
>то он должен автоматически деинсталлироваться, затирая за собой все следы (вдруг
>пользователь зашел с какого-нибудь интернет кафе). Так же предполагается, что данным
>сервисом будет пользоваться и высокое рукамиводство, которое любит, чтобы все работало
>с нажатия на одну кнопочку.man ssh
man sshd
man corkscrew
>[оверквотинг удален]
>>проблема усложнена еще и тем, что после того, как пользователь поработал на
>>чужом компьютере, ничего не должно оставаться. т.е. если и запускался клиент,
>>то он должен автоматически деинсталлироваться, затирая за собой все следы (вдруг
>>пользователь зашел с какого-нибудь интернет кафе). Так же предполагается, что данным
>>сервисом будет пользоваться и высокое рукамиводство, которое любит, чтобы все работало
>>с нажатия на одну кнопочку.
>
>man ssh
>man sshd
>man corkscrewИ, если почле вышенаписанного еще есть желание пилить - пилите
>man ssh
>man sshd
>man corkscrewСпасибо, посмотрю, что это такое. но если не ошибаюсь, то это только проброс ssh через прокси... хотя там, наверное можно порты мапить...
Из беплатных реализаций VPN SSL серверов работающих через браузер есть ssl explorer, но и тот уже перекупили и он перестал развиваться как бесплатный продукт, посмотрите на аппаратные реализации к примеру juniper ssl vpn
Посмотрите http://fosswire.com/post/2008/06/using-ssh-as-an-ad-hoc-vpn/ достаточно просто можно и кнопочку придумать
>Посмотрите http://fosswire.com/post/2008/06/using-ssh-as-an-ad-hoc-vpn/ достаточно просто можно и кнопочку придуматьЭто все хорошо, но ssh через проклю не пройдет...
>>Посмотрите http://fosswire.com/post/2008/06/using-ssh-as-an-ad-hoc-vpn/ достаточно просто можно и кнопочку придумать
>
>Это все хорошо, но ssh через проклю не пройдет...Ну тогда SSL Explorer или его наследника OpenVPN ALS (http://adito.sourceforge.net), ну или corkscrew под win через Cygwin с ssh для каждого клиента. Ни первое ни второе сам не пробовал.
>Это все хорошо, но ssh через проклю не пройдет...
> Из беплатных реализаций VPN SSL серверов работающих через браузер есть ssl explorerOpenVPN отлично работает через прокси, но только по tcp протоколу. Хотя авторы рекомендуют использовать UDP по возможности, так как при TCP over TCP могут возникать проблемы. Лично сам использую udp/tcp каждый протокол на своем интерфейсе. Пока проблем не было. единственный минус - надо ставить клиента.