есть ли windows решения VPN over SSh не на уровне прокси а на уровне ethernet интерфейса?


т.е. чтобы создавался сетевой интерфейс как при использовании OpenVpn трафик шел через него, заворачивался на ssh(весь включая udp и dns запросы).

желательно фри/опенсорс.

Комментарии
Гость (05/03/2012 08:41)   
SSH под виндой — протокол прикладного уровня, он пропускает через себя tcp-соединения в режиме прокси, а не произвольные сетевые пакеты как VPN. В принципе, можно сделать какую-нибудь эмуляцию, но это будет уже не чистый ssh. Насчет готовых решений мне не известно.

OpenVPN, например, работает на сетевом уровне: он именно создает виртуальный адаптер и транслирует пакеты. В ssh же надо заворачивать не пакеты, а соединения (это более высокий уровень сетевого стека), ну или делать эмуляцию, т.е. создавать адаптер, декодировать пакетный уровень, заворачивать соединения в ssh. В винде есть два способа так сделать: первый и простой — вклиниться в сетевой стек на канальном уровне, перехватывать tcp- и udp-сокеты и заворачивать трафик в ssh (это делают разные программы-проксификаторы). Второй и сложный — создать виртуальный сетевой адаптер (как это делает OpenVPN), и сделать слой трансляции сетевого уровня в канальный, т.е. «обратный» tcp/ip стек (такое решение используется, к примеру, во внутреннем NAT'е проекта VirtualBox).
Гость (06/03/2012 21:45)   
Странная хотелка... SSH вообще-то shell.
А если есть сетевой интерфейс тут, то и там он тоже должен быть. Чего SSH никак не умеет. Он же shell :(

http://openvpn.net/index.php/o.....hernet-bridging.html[link1]
Чем не устраивает?
Ну и для большего извращения можно заставить OpenVPN работать через заранее поднятый SSH-тоннель.
Гость (06/03/2012 22:32)   
Ну и дополняя предыдущего оратора – на LOR
https://www.linux.org.ru/forum.....astmod=1330986139255[link2] не тот же самый автор?
Там в комментах есть соотв. костыли. Но, опять же, требуется сетевой интерфейс. А коли есть возможность сделать интерфейс, OpenVPN выглядит намного более устойчивым решением.
Гость (07/03/2012 00:36)   
а как же тогда под линуксами с ключем -w поднимают чз ssh tun/tap виртуальную сетевуху?
Гость (07/03/2012 00:51)   
в идеале хотелось бы решения чтобы можно было так затунелироваться как между win2win так и win2lin
Гость (07/03/2012 15:43)   
В идеале хотелось бы, чтоб win считалась оффтопиком, и посты про win удалялись.
— unknown (07/03/2012 16:22, исправлен 07/03/2012 16:22)   

Можно просто игнорировать эти посты. Если спрашивающие поймут, что осмысленного ответа искать не у кого, то и спрашивать не будут.

Гость (09/03/2012 02:33)   
посты про win удалялись.
Предлагаете удалить из рубрики софт[link3] DiskCryptor, FreeOTFE, Eraser, Gpg4win, PasswordSafe ?

Просто игнорируйте. :)
Гость (09/03/2012 06:39)   
Предлагаете удалить из рубрики софт DiskCryptor, FreeOTFE, Eraser, Gpg4win, PasswordSafe?

Ну... скорее предложу создать отдельный раздел под win, о чём, кстати, нам явно намекает опрос на главной странице :)

На самом деле тут единственный ответ в топик по сути — первый пост[link4]. Между прочим, это мой пост: я, будучи линуксоидом, не поленился спросить мнение у небезызвестного здесь win-специалиста по поводу этого вашего вопроса и запостить ответ. Этот первый коммент появился 5 дней спустя после топика: если б я не приложил усилия, тут бы вообще постов не было, никаких (да, сам виноват, понимаю). Мне просто хочется, чтобы все, конструктивно ищущие помощь на pgpru, находили её, и я прикладываю к тому все усилия. Короче, считаю, что у меня есть право на шутку про win[link5] :) Нет, ну действительно. Уже дошли до перлов «убунты не нужны[link6]». Задолбали засирать форум своей виндой! :)
— unknown (09/03/2012 13:38)   
Ох уж эти шутки[link7].
Гость (17/03/2012 02:54)   
спасибо за посильное участие в развитии этого вопроса, но перейти на линукс не так просто как кажется обычному линуксоиду, тем более что виндовсом пользуется в десятки если не сотни раз больше людей чем линуксом. по офф данным тех же пользователей мак ос больче чем линукс ;) так что действительно будьте толерантней к той ос на которой сидит 97% пользователей потому что если они перейдут на линукс вы захлебнетесь в потоке вопросов.
Гость (17/03/2012 21:23)   
Обсуждалось в районе /comment38386[link8]. Когда у виндузятника возникают вопросы, часто оказывается, что дело не в сложности, а в том, что он даже не пытался[link9] гуглить ответ.
если они перейдут на линукс вы захлебнетесь в потоке вопросов.
Тоже верно :)
Гость (18/03/2012 08:52)   
А на сколько надежны туннели через ssh по сравнению например с традиционным openvpn?
Гость (18/03/2012 18:16)   
Зависит от того, что вы лучше знаете. При грамотной настройке оба достаточно надёжны, но разобраться с нуля с ssh-тунелями, имхо, намного проще.
OpenVPN должен быть, конечно, на сертификатах, а не на паролях.
Гость (19/03/2012 01:19)   
Да, туннель сделать явно проще. Настройка стандартная, никакой дополнительной защиты, авторизация ssh по логин:пароль. Все ок., траф перенаправляется и шифруется. Нужно ли что нибудь сделать дополнительно?
Гость (19/03/2012 01:28)   

Лучше по ключам сделайте. Оно же просто делается, куча манулов по интернету, погладьте их.


В правилах iptables/pf разрешите пакеты нужному user'у только с IP-адреса/интерфейса, ассоциированного с данным туннелем. Полностью запретите IPv6 и ICMP-трафик с вашей машины.
Гость (19/03/2012 01:35)   

Заодно в authorized_files можете прописать разрешение авторизовываться только с определённого IP, обсуждалось в /comment36073[link10] (конфиг pf там не вполне безопасен, т.к. разрешает ICMP-пакеты).
Гость (19/03/2012 13:10)   
Есть непонимание, каким образом генерируется и передается открытый ключ с локальной машины на сервер. Серверный я получаю...
Гость (19/03/2012 17:24)   

Теоретически надо бы дать его админу, чтобы он положил его в ~/.ssh/authorized_keys. За неимением доступа к админу обычно приходится довольствоваться тем, что 1ый раз входите по паролю, затем загружаете сами туда свой открытый ключ (sftp или scp), а следующие разы авторизуетесь только по ключу.
Гость (19/03/2012 17:34)   

$ ssh-keygen -C "комментарий, чтобы знать, что за ключ" -f ~/.ssh/NAME.ssh -b 2048 -v -t dsa
В качестве NAME удобно взять IP-адрес или DNS-имя сервера. В каталоге ~/.ssh появятся два файла: ~/.ssh/NAME.ssh — ваш приватный ключ и /.ssh/NAME.ssh.pub — ваш публичный. На сервере и в домашней директории на клиенте надо проследить за тем, чтобы у других пользователей не было прав доступа к ~/.ssh: сделать
$ find ~/.ssh -exec chmod go-rwx {} \;
иначе авторизация по ключам не заработает.
Гость (24/03/2012 19:34, исправлен 24/03/2012 20:08)   

/comment51316[link11]


а матерые линуксятнике давая ссылки даже не утруждают себя проверкой их работоспособности
по иронии судьбы http://unix-like.info/ сейчас варезняк с софтом под винду :D

Гость (29/03/2012 23:49)   
Наверное я действительно непонимаю нечто основопологающее. Каким образом осуществляется шифрование если авторизация проходит только по логин:пароль? Ведь сервер в данном случае не имеет ключа клиента?
— SATtva (31/03/2012 09:28)   
Ключи и пароли — это средство аутентификации. Шифрование канала в любом случае производится сеансовым ключом.
Гость (01/04/2012 01:52)   
Да, я так и понял. То есть при аутентификациии по логин:пароль на локальную машину приходит ключ с сервера. Кстати при реконнектах он не меняется(это сеансовый?). Запросы шифруются этим ключем, передаются серверу. Каким образом шифруется ответ?
— SATtva (01/04/2012 09:11)   
Стороны совместно вырабатывают ключ по Диффи-Хэллману при установлении соединения, на этом же этапе приосходит аутентификация сервера, см. RFC 4253[link12]. Ключ не только уникален для каждого сеанса, но и периодически пересогласовывается в рамках одного сеанса.
— Гость (01/04/2012 17:57)   
кстати знатоки ssh – ведутся ли логи соединений через него?
— SATtva (01/04/2012 22:06)   
Это уж как админу сервера заблагорассудится. :) Обычно факт логина фиксируется.
Гость (02/04/2012 02:04)   
Запросы шифруются этим ключем, передаются серверу. Каким образом шифруется ответ?
На тему SSH недавно уже был топик[link13] :) На уровне PoC (а не в SSH) подобные протоколы могли бы работать подобно PGP:
  1. Сервер высылает клиенту ключ
  2. Клиент проверяет его отпечаток
  3. Клиент шифрует свой публичный ключ публичным ключом сервера и передаёт ему
  4. Сервер и клиент имеют ключи друг друга. Каждый может шифровать сообщения и посылать один другому.
Для отсылки сообщения Алиса генерирует случайный пароль, шифрует им передаваемое сообщение, а сам пароль шифрует ключом Боба. Оба шифртекста (как шифрованный ключом пароль, так и сами данные, шифрованные этим паролем) пакуются в один PGP-пакет и посылаются в сеть. Ответ от Боба Алисе посылается аналогично. Так работает [вроде бы], PGP-шифрование в XMPP.

знатоки ssh – ведутся ли логи соединений через него?
По умолчанию? Наверное, зависит от ОС. В /var/log/authlog бывает информация типа следующей:
Nov 20 22:32:14  sshd[991]: SSH: Server;Ltype: Version;Remote: IP-52671;Protocol: 2.0;Client: OpenSSH-VERSION OS-VERSION
Nov 20 22:32:15  sshd[991]: Accepted publickey for USER from IP port 52671 ssh2
Nov 20 22:32:15  sshd[2488]: subsystem request for sftp
Nov 20 22:32:33  sshd[2488]: Received disconnect from IP: 11: disconnected by user
...
Jan 22 02:25:13  sshd[2427]: error: connect_to IPv6-ADDRESS port 80: No route to host
Ну и на last смотрите. Детализации всех сетевых соединений, как видите, нет, но, например, ошибка соединения с каким-то адресом по тунелю (ssh -D порт) осела в логах. На публичных системах, если админ не враг сам себе, он настраивает систему логов, и тут уже кто во что горазд... Следует отметить, что
  1. При логине по ssh клиент светит версию своего клиента и ОС.
  2. При пользовании опцией -N при открытии тунелей записи в last не создаётся (зато создаётся в /var/log/authlog, хотя за все системы не поручусь).
— unknown (02/04/2012 09:47)   
На уровне PoC (а не в SSH) подобные протоколы могли бы работать подобно PGP:

Такой протокол когда-то существовал, не помню для OpenSSH или OpenVPN. Он устаревший, по причине того, что нет смысла переносить изначально оффлайновые протоколы в онлайн-сессию. Реальный протокол основан на согласовании эфемерного ключа Диффи-Хеллмана со сверкой подписи отпечатков и выведении из него симметричного ключа сессии. Это даёт преимущество в том, что так в онлайн-протоколах естественным образом появляется свойство "наперёд заданной секретности" (Perfect Forward Security) — PFS. Будущие потенциальные компрометации ключей (MITM, взлом серверов, похищение ключей, но естественно не полный криптоаналитический взлом) не позволяют расшифровать предыдущие нескомпрометированые сеансы.
Гость (02/04/2012 17:56)   
Есть два способа построения vpn через ssh:

1. ppp через ssh. Если есть сервер pppd под windows, то наверное можно сделать по аналогии с linux. Рецептов в Интрернете множество, например http://citforum.ru/operating_systems/linux/linux_vpn/

2. Построение туннеля средствами одного ssh с помощью опции -w. Для этого нужно установить драйвер виртуального интерфейса tun, под windows он вроде есть.

Второй способ требует рутовый вход на ssh сервер, поэтому менее безопасен. Хотя наверное можно создать пользователя и наделить его нужными привилегиями, но в данном случае это не совсем просто.

Ещё вариант – установить cygwin, тогда vpn наверное строится в точности как в linux.
Гость (09/04/2012 09:54)   
ppp через ssh.
Интересное извращение :)

Построение туннеля средствами одного ssh с помощью опции -w. Для этого нужно установить драйвер виртуального интерфейса tun, под windows он вроде есть.
Ага, только ssh под винду нет — есть putty.exe. Покажите мне аналог -w в документации на putty :)

Второй способ требует рутовый вход на ssh сервер, поэтому менее безопасен
Да не особо. Достаточно в нужном ключе в /root/.authorized_file указать параметр command и сделать вход только по ключам. Имея нужный ключ, сервер нельзя будет заставить сделать ничего кроме конкретно того, что прописано в command (разовое выполнение какого-то скрипта или команды). Доступ к шеллу получить не удастся. Для пущей надёжности можете прописать PermitRootLogin forced-commands-only в /etc/ssh/sshd_config. Обсуждалось в /comment49362[link14].
Гость (09/04/2012 10:13)   
Такой протокол когда-то существовал, не помню для OpenSSH или OpenVPN. Он устаревший, по причине того, что нет смысла переносить изначально оффлайновые протоколы в онлайн-сессию. Реальный протокол основан на согласовании эфемерного ключа Диффи-Хеллмана со сверкой подписи отпечатков и выведении из него симметричного ключа сессии.

Верное замечание. Просто то было первое, что пришло в голову :) Действительно, современный OTR в XMPP именно так и работает. Жаль только, что оффлайново не может — мог бы ведь юзать ключ тот, который был в последнем сеансе, технически это ничему бы не противоречило, достаточно договориться о стандарте. С другой стороны, OTR маргинален как по длине ключей и алгоритму (AES-128 без каких-либо альтернатив вообще, если ничего не путаю), так и по степени распространённости и поддержке у клиентов. Вот это, вкупе с невозможностью писать в оффлайн, сильно его маргинализирует :(

Кстати, на PGP в джаббере есть вроде бы 2 разных стандарта:
1. end2end PGP (какой-то новый стандарт, поддерживается в gajim).
2. Просто шифрование stanza'ий (устаревший, но самый популярный способ среди jabber-клиентов; судя по обсуждениям в этом топике[link15], он имеет существенные недоработки, типа невозможности подписывать и шифровать сообщения одновременно).
— unknown (09/04/2012 12:11)   
Жаль только, что оффлайново не может — мог бы ведь юзать ключ тот, который был в последнем сеансе, технически это ничему бы не противоречило, достаточно договориться о стандарте.

Его специально делали только онлайновым, иначе зачем OTR? Сохранение ключа разве не нарушит саму идею?
OTR маргинален как по длине ключей и алгоритму (AES-128 без каких-либо альтернатив вообще

Вероятно это из стандартного набора OpenSSL.

Впрочем, OTR здесь только для иллюстрации. В целом — это оффтопик.
Гость (09/04/2012 13:31)   
Сохранение ключа разве не нарушит саму идею?
Имхо, нет: при первом же следующем выходе абонента в онлайн ключи могли бы меняться на другие [rekeying или как там это в протоколах называется, ротация ключей короче ;)]
Вероятно это из стандартного набора OpenSSL.
Не знал, что в стандартном наборе OpenSSL есть только AES. Номинально OpenSSL не только AES поддерживает. Ну, и что такое «стандартный набор» мне не очень понятно.
— unknown (09/04/2012 13:58)   
http://www.openssl.org/docs/apps/ciphers.html
В симм. шифрах (видимо по соображениям политкорректности) присутствуют GOST и CAMELLIA. Ну и для обратной совместимости всякое старьё.
Гость (09/04/2012 17:59)   
Гость 09/04/2012 09:54

ppp через ssh – это исторически один из первых способов построения vpn. Более последовательно реализует концепцию vpn – тунеллирование канального трафика (ppp) через защищённый протокол (ssh). Более универсальный, т.к. позволяет использовать для туннелирования другие защищённые протоколы: ppp через ssl средствами stunnel, ppp через pptp и т.п. Больше соответствует философии unix, когда система конструируется из независимых частей, каждая из которых выполняет свою специфическую функцию. vpn на одном ssh -w – решение "всё в одном", менее производительное, потому и называется poor man vpn. Команды в forced-commands-only требут привилегий рута и бывали случаи когда ограничение на список команд обходилось.
Гость (10/04/2012 03:09)   
ppp через ssh – это исторически один из первых способов построения vpn.
Исторически у нас были звонки на модемы, царство виндов на всех машинах, а также монопольное царство MS в плане своих протоколов. В этом плане история ppp изначально замаратая. Поддержка этих протоколов тоже... много магии. man pppd символизирует (вы его читали? Я вот читал, например). Они, имхо, устарели, а вот пришло ли им что взамен — не ясно. Во всяком случае, ppp-соединения с провайдерами как были костылями ещё в давние времена, так ими остались и до сих пор. И вой на тему «как мне настроить pptp-соединение с таким-то провайдером» не утихает и поныне[link16]. Насколько мне известно, построение VPN-сетей через ppp в открытых системах не является ни рекомендованным, ни каноническим. Это воспринимается только как неизбежное зло, потому что некоторым провайдерам наплевать на то, что помимо винды есть другие системы. Со стороны это смотрится так же, как если бы кто-то сделал доступ в интернет через ключи в OpenVPN (или NAT на ssh -w), а отсутствие оных на машинах пользователей его бы никак не волновало.

vpn на одном ssh -w – решение "всё в одном", менее производительное
Что, если вы в ssh завернёте весь ppp-трафик, оно магическим образом станет более производительным? Узкое место — в самом ssh, насколько я знаю, а не в способах передачи данных в туннель.

бывали случаи когда ограничение на список команд обходилось.
Ссылки на багрепорты можно увидеть? И я сказал про forced-commands-only только как про дополнительный довесок. Основное — команда command в authorized_keys, которая в принципе не позволяет получать шелл.

В симм. шифрах (видимо по соображениям политкорректности) присутствуют GOST и CAMELLIA. Ну и для обратной совместимости всякое старьё.
Странно, что нет такой классики как, например, blowfish. Вроде это совсем не новый шифр, но достаточно добротный из «стареньких».
Гость (10/04/2012 10:32)   
http://www.openssl.org/docs/apps/ciphers.html
В симм. шифрах (видимо по соображениям политкорректности) присутствуют GOST и CAMELLIA. Ну и для обратной совместимости всякое старьё.
Строго говоря, вы дали ссылку только на ман по тем шифрам, которые в SSL/TLS юзаются; да и то этот ман by def устаревший (ибо пофиг). В самом OpenSSL есть дофига всего и blowfish, естественно, тоже (правда, сильно новых шифров нет).
Гость (10/04/2012 18:05)   
Не знаю чем устарел ppp, он по прежнему востребован. Я не эксперт в pppd, но ppp-over-ssh настроил за разумное время, с тех пор работает стабильно как часы. Достаточно немного поиграть с опциями, а лучше воспользоваться готовым рецептом от профессионалов (ссылку уже приводил). Для персонального использования это по-видимому наилучшее решение (об этом пишут авторы книги, см. ссылку). Простой bash-скрипт заменяет целый комбайн под названием openvpn.

Про обход ограничения команд в ssh читал давно (возможно это относилось к 1-й версии), ссылку искать нет времени. Можете не верить. Меньшая безопасность ssh-w следует и из общих соображений. Чтобы взломать сервер с ppp-ssh нужно обойти ограничения ssh (тоже используется ограничение на возможные команды), а потом – ограничения системного пользователя под которым осуществляется vpn-подключение. Т.е. сначала защита обеспечивается приложением (ssh), затем – системой (права доступа). В ssh-w достаточно обойти только ограничения ssh.
Гость (11/04/2012 08:49)   
Не знаю чем устарел ppp, он по прежнему востребован.
Востребован теми, кто является ISP, потому что ISP ориентируется на уменьшение телодвижений по настройке интернета у пользователей. Наличие клиента в умолчальной винде здесь играет ключевую роль. Если же делать чисто для себя, то уже давно есть современные протоколы для того же самого: для подключения к провайдеру — l2tp и sstp, для деления локалки на сегменты – vlan. Для шифрования трафика — IPSec.

Ссылки
[link1] http://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html

[link2] https://www.linux.org.ru/forum/security/7476681?lastmod=1330986139255

[link3] http://www.pgpru.com/soft

[link4] https://www.pgpru.com/comment50988

[link5] https://www.pgpru.com/comment51079

[link6] https://www.pgpru.com/comment50954

[link7] https://www.pgpru.com/comment46295

[link8] https://www.pgpru.com/comment38386

[link9] https://www.pgpru.com/comment25825

[link10] https://www.pgpru.com/comment36073

[link11] https://www.pgpru.com/comment51316

[link12] https://tools.ietf.org/html/rfc4253

[link13] https://www.pgpru.com/forum/kriptografija/kakperedaetsjaparoljvssh

[link14] https://www.pgpru.com/comment49362

[link15] https://www.pgpru.com/comment25960

[link16] https://www.pgpru.com/comment25823