ssh vs (ipsec | openvpn | pptp)

Сложность настройки - основной фактор? Или и в производительности есть различия?

Основной фактор - надёжность.

Главное - перестать путать теплое с мягким.
Например, Secure Shell с Virtual Private Network.

Вы не знаете, как сделать второе с использованием первого?

ssh показало себя с плохой стороны в этом отношении?

Вы не знаете, как сделать второе с использованием первого?

Я опять-таки рекомендую не разводить клоунаду, ибо проброска нескольких портов, указанных вручную - ни разу не VPN.

не нужно делать мешанину. openssh - для одних целей, а openvpn - для других.

основной фактор

чтобы сделать выбор, нужно прочитать про все эти технологии и выбрать то, что подходит в конкретной ситуации.

ssh показало себя с плохой стороны в этом отношении?

нет. просто изначально ssh - это персональный админский инструмент, а не средство для роутинга сетей.

ssh показало себя с плохой стороны в этом отношении?

Дело не в ssh, а в самописных костылях, которые из ssh делают vpn.

я довольно долго ковырял этот вопрос, и получилось, что таки вполне можно соединить две через ssh-туннель с шлюза одной сети до шлюза другой сети так, что доступ будет прозрачный. Линуксовый программный мост позволяет шлюзу сделать вид, что его порт, смотрящий в локалку, и порт шлюза другой сети, смотрящий в локалку, являются портами одного L2 свича.

Ну вот, уже и на это ответили выше.

Не городи костыли. Впн это впн, ссх это ссх.

Окей, ответ получен. Создам ещё один тред, если когда-нибудь успешно внедрю схему с ssh, и она проработает вменяемое время без косяков (туннель, который я использую для связи с одной сеткой, где время от времени возникают вендопроблемы, не в счет - его кроме меня никто не видит)

Торренты через sshпогоняй, а потом сеть в 1gbit сеть со 100 мегабитами постоянной.
Если у тебя взлетит и будет стабильно работать - ну круто, чо.

проброска нескольких портов

блджад, ssh умеет не только это! SOCKS-proxy ты благополучно забываешь, к примеру? Но всё это не меняет того факта, что принятые решения(pptp,ipsec,openvpn) были приняты не зря...

есть мнение, что помрет даже решение с IPSEC. Потому что, мне кажется, чтобы прокачать на PC-роутере больше 100 мегабит с шифрованием(ESP) процессор потребуется очень нехилый. Или я чего-то не знаю и гигабиты шифрованного трафика уже не требуют спецжелезок(или по настоящему могучих процов)?

SOCKS-proxy

Тоже ни разу не VPN :)

так я и не спорю. Просто ЕМНИ можно и туннели на нём поднять(полноценные, с интерфейсами а-ля tun0), но я этим никогда не заморачивался

P.S. Почему-то вспомнился проекты pppoj(PPP over Jabber). Кстати, на ЛОРе о нём постили вроде бы :-)

Вообще ssh умеет tun-девайсы юзать. Но это, разумеется, костыль.

100 мегабит вроде как даже весьма среднее железо сможет держать.
Только вот ssh на моей практике загнулся и на куда меньших скоростях.

Может я не понял о чем ты, но у меня сейчас на ксеончике (2.6 GHz) висит openvpn который не сильно жрет процессор и пропускает свозь себя вроде под 300 мегабит.

Ну у меня проблема была простая.
Как только через начинает пропускать сквозь себя множество коннектов, то задыхается.

Т.е одно дело использовать его для проброса VPN, а другое для сервера с кучей быстро прерывающихся соединений.

Ну а вообще в сетях я дилетант, увы.
Возможно что то не так настроил или не знал куда копать.

Просто как то нужен был проброс приложения к которому куча запросов прет (до 3000 в минуту).
Так вот через ssh все работало очень и очень плохо.

Окей, нашелся заинтересовынный человек - постараюсь устроить нагрузочное тестирование такому каналу.

s/ы/а/

Дело не в ssh, а в самописных костылях, которые из ssh делают vpn.

костыли минимальные - крон с проверкой и переподключением по необходимости, да пара tap-ов в /etc/interfaces

работает второй год, разрывы только по внешним причинам.

Если нужно просто соединить две машины для проброса интернета - не вижу смысла колдовать с openvpn.

Устрой, интересно посмотреть на результаты.
Ну и ман с историей успеха если все будет хорошо работать.

почти джва года по подобной схеме, причем если раньше просто напрямую, то сейчас всё это работает ещё и через cntlm через проксю

http://linuxoid.in/VPN-туннель_средствами_ssh

если вдруг интересно, как у меня (примерно, убраны cntlm и роутоспецифичные заморочки) настроено

да, сервером - p3-933, канал по которому цепляюсь - 4/2мбита. Раньше был через 20Мбитный, но он достаточно ненадежен (билайн), да и прокся в дневное время нагружена достаточно сильно, так что переключился на второй.

Завтра, может, повнимательнее прочитаю, но dhcp у меня сегодня через tap взлетел.

dhcp у меня сегодня через tap взлетел.

жду подробностей

ну, если так, то круто :-)

Так.

Дано: сервер (server, интерфейс eth1 смотрит в локалку, адрес интерфейса - 10.0.0.100/24, интерфейс eth0 смотрит вовне), клиент (client, единственный интерфейс - eth0 - смотрит в локалку, адрес - 192.168.1.1/24). В локалке сервера есть dhcp-сервер, от которого, в которой работает dhcp, который и раздал имеющийся адрес.

Нужно: позволить клиенту получить адрес по dhcp из локалки сервера.

Делаем:

server# brctl addbr br0
server# brctl addif br0 eth0
server# dhclient br0

client# ssh -w 0:0 -o tunnel=ethernet server -fN

server# ifconfig tap0 up

client# dhclient tap0

И клиент получает адрес из 10.0.0.0/24 на свой tap0. Если хотим, чтобы в локалке клиента любой комп тоже мог получить адрес из 10.0.0.0/24 по dhcp, то заводит клиенту ещё один интерфейс - eth1 - и делаем

client# brctl addbr eth1
client# ifconfig eth1 up

После этого в локалке клиента должен стать доступен dhcp из локалки сервера.

Проверял все, кроме последнего шага - его проверю, может быть, сегодня.

SSL - защита сеансового уровня, а vpn - сетевого (man модель OSI).

Tunnel Request tun(4) device forwarding between the client and the server. The argument must be “yes”, “point-to-point” (layer 3), “ethernet” (layer 2), or “no”. Specifying “yes” requests the default tunnel mode, which is “point-to-point”. The default is “no”.

man ssh_config

У openvpn/ssh архитектурно различий не будет, а вот с ipsec эти самые различия огромны.

В любом случае, IPSEC - S2S, OpenVPN/SSH - C2S

Не соглашусь. Я уверен, что с ssh можно сделать s2s, как только сделаю - покажу.

насколько я помню, в самом man ssh не рекомендуется использовать его для VPN в продакшене :)

вот, нашел

Since an SSH-based setup entails a fair amount of overhead, it may be more suited to temporary setups, such as for wireless VPNs. More permanent VPNs are better pro‐ vided by tools such as ipsecctl(8) and isakmpd(8

Если ssh внезапно умеет TAP - можно конечно. Но

http://i29.fastpic.ru/big/2011/1006/df/658ecd124c4502882e218a2e30ee7bdf.jpg

Реквестирую подпись к картинке :)

Ну да, в общем, мне поверили, что оно это умеет, а насчет fair amount of overhead - ну правда, наверное, раз пишут. Но через ssh все рввно душевнее)

s/в/а/6

Ну конечно правда. Tap - это вывод из ядра в юзерспейс, обработка в юзерспейсе и путь обратно в ядро. То что в нормальных условиях занимает микросекунды, начинает занимать мили. Не считая избыточной упаковки, протоколов гарантированной доставки поверх протоколов гарантированной доставки и прочих мелких радостей

О. Из ядра в юзерспейс. Да, это все объясняет. Fuse вроде те же проблемы имеет, и по той же причине.

А когда используют openvpn, tap тоже присутствует - там он жить не мешает?

tap - это везде двойной путь ядро-юзерспейс-ядро

Если хочется чисто ядерного тоннеля и с шифрованием, не гоняя траффик в юзерспейс, то варианты такие: L2TP/IPSEC, просто IPSEC из ядра или StrongSWAN, PPP/MPPE, может еще что забыл.

Впрочем, OpenVPN вполне хорошо работает и гораздо удобнее в использовании. С шифрованием AES-256-CBC и авторизацией пакетов через SHA1 он у меня переваривает 100 мегабит даже на совсем уже не новом Core 2 Duo E8500 и еще запас некоторый остается. Можно даже раскидать канал на два и более ядер, если сделать несколько туннелей и объеденить их через bonding. Так каждый процесс OpenVPN будет шифровать на своем ядре.

С переваливанием через tun проблема не в скорости - и до гигабита догнать можно, а в латенси.

По сравнению с интернетами тамошним латенси можно пренебречь, я думаю. Да и в 99% других случаев тоже.

Вот сейчас померял пинги между OpenWRT роутером с OpenVPN и х86 сервером с AES-256/SHA1 - в среднем 0.85ms против 0.3ms напрямую без туннеля.

Принципиальное различие в том, что туннелирование IP трафика поверх TCP канала (как в SSH) на порядок тормознее чем туннелирование IP поверх IP (или UDP), как в OpenVPN/L2TP/IPsec.