Соединение нескольких офисов в одну сеть с помощью OpenVPN

Какие алгоритмы шифрования поддерживает?
Можно ли использовать с криптопровайдером CryptoPro?

Оно использует openssl со всеми вытекающими...

Чем это решение лучше GRE тунеля? Использую GRE для соединения 2 офисов (Debian)

А чего, есть кто-то кто не умеет этого? Или умельцы, что гонят чистый без шифрования трафик? :)

>Чем это решение лучше GRE тунеля? Использую GRE для соединения 2 офисов
Тем, что GRE не везде проходит. Если у вас два офиса, уже работающее решение и нет планов к расширению/смене провайдеров - не трогайте.

Не совсем понял зачем размещена эта статья? :-(( Любой нормальный админ сделает vpn в течение суток.

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

у нас tinc юзается (debian)

>Чем это решение лучше GRE тунеля? Использую GRE для соединения 2 офисов (Debian)

GRE некоторые провайдеры зарезают.. А openvpn работает на базе TCP и UDP и может работать даже через прокси.. Так что openvpn рулит!

С другой стороны, как уже было написано, если у вас уже есть решение для вашей компании на базе GRE, и оно хорошо работает, то нет смысла менять его.

Я бы назвал эту статью "очень короткое начало работы с openvpn". Полезно тем, кто никогда раньше вообще ничего подобного не делал.

>А чего, есть кто-то кто не умеет этого?

Есть те, кто никогда этого не делал...

> Есть те, кто никогда этого не делал...

Полностью поддерживаю. Господа, не забывайте, что здесь не все опытные администраторы, а также есть те, кто хочет чему-то научиться. Вместо того чтобы писать о своих достоинствах, лучше бы статью какую-нибудь подобную написали, полезную для менее опытных, чем вы. Многие за это были бы вам благодарны.

Такими статьями весь Интернет забит.

С реальными адресами любой дурак сделает. А вот пусть попробуют забацать vpn между только серыми адресами.

Разъясните пожалуйста, что лучше использовать для объединения нескольких небольших офисов: openvpn или tinc?

>Сервер под управлением Ubuntu Linux

Дальше читать не стал...

> Не совсем понял зачем размещена эта статья? :-(( Любой нормальный админ сделает vpn в течение суток.

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

если ты называешь админом человека, которому на поднятие vpn понадобиться сутки... то давайте публиковать на ЛОРе маны. :)

а по теме на linux машинах для таких задач сносно работает gre+ipsec.

+1!
любой нормальный админ имеет врожденный талант поднимать впн силой мысли за 10 сек. Остальные - убейте себя апстену. :)

Разъясните пожалуйста, что лучше использовать для объединения нескольких небольших офисов: openvpn или tinc?

IPSEC

Правильно ли я понял что тут ip завернули в tcp? Спорный выбор.

> IPSEC

А аргументация?

в udp

>> IPSEC

>А аргументация?

ipsec стандарт и включён в ipv6

(pptp ни разу не стандарт)

Как я понял openvpn обеспечивает туннельное шифрование?
А есть ли под линукс продукты, позволяющие создавать VPN-сети с шифрованием траффика на каждом клиенте, дабы снизить проседание канала?

простите, но опенвпн ничем не отличается от ssh+pppd.
я применял именно эту связку, ибо товарищи, обслуживающие сервер, сильно тормозили с установкой впн.

ничего не сказано, что в iptables надо открывать/пропускать для работы канала. Как-то совсем коротко получилось...

И почему без "ping-restart"? Типа канал не падает никогда?

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

Просто наблюдал такую картину: было примерно два одинаковых интернет канала, через них гонится VoIP траффик. Через один был проложен OpenVPN туннель (шифрование и сжатие отключили), через второй IPSec. Так вот, IPSec давал намного меньшие задержки по сравнению с OpenVPN.

> простите, но опенвпн ничем не отличается от ssh+pppd.

Отличается. openvpn может работать поверх UDP, ssh+pppd - нет. А в случае туннелирования большого tcp-трафика внутри tcp соединения (в данном случае - ssh) довольно быстро соединение полностью затыкается (связано это с тем, что контроль передачи работает сразу на двух уровнях - на уровне tcp по которому идёт ssh и на уровне туннелируемого соединения; в итоге при потере пакета соединение подвисает намертво - помогает только разорвать его и заново соединиться. У меня при связи между двумя компами, воткнутыми в один свитч (куда ещё и провайдерская сетка была подключена) такой затык наступал после передачи 20-50мб на максимальной скорости). Так что ssh+pppd можно рекомендовать только если нет возможности установить нормальный vpn поверх udp или голого ip.

Да и вообще, в послдених версиях openssh есть свой vpn, так что pppd тут не нужен.

>OpenVPN - очень удобная штука, только вот одно мне в нём не нравится - он вносит ощутимые задержки в прохождение пакетов, особенно на плохих каналах.

используйте udp :-)

http://ru.gentoo-wiki.com/HOWTO_%D0%A1%D0%BE%D0%B7%D0%B4%D0%B0%D0%BD%D0%B8%D0...

>Отличается. openvpn может работать поверх UDP, ssh+pppd - нет. А в случае туннелирования большого tcp-трафика внутри tcp соединения (в данном случае - ssh) довольно быстро соединение полностью затыкается (связано это с тем, что контроль передачи работает сразу на двух уровнях - на уровне tcp по которому идёт ssh и на уровне туннелируемого соединения; в итоге при потере пакета соединение подвисает намертво - помогает только разорвать его и заново соединиться. У меня при связи между двумя компами, воткнутыми в один свитч (куда ещё и провайдерская сетка была подключена) такой затык наступал после передачи 20-50мб на максимальной скорости). Так что ssh+pppd можно рекомендовать только если нет возможности установить нормальный vpn поверх udp или голого ip.

1) поверх UDP - это дикая экзотика.

2) связка соединяет и серые сети, если есть доступ к шеллу промежуточного сервера.

3) да ничего там не затыкается. работало сутками, прошло много гигабайт.

>С реальными адресами любой дурак сделает. А вот пусть попробуют >забацать vpn между только серыми адресами.

В чем трабла?

Пишешь те адреса, к-рые считаешь нужным в качестве внешнего. Хоть серые, хоть белые, хоть в полоску.

> 1) поверх UDP - это дикая экзотика.

Во-первых, все современные vpn-решения для линукса (openvpn, tinc, cipe, vtun) умеют работать поверх udp. Во-вторых, это самый правильный способ - http://sites.inka.de/~W1011/devel/tcp-tcp.html

>>С реальными адресами любой дурак сделает. А вот пусть попробуют >>забацать vpn между только серыми адресами.

>В чем трабла?

>Пишешь те адреса, к-рые считаешь нужным в качестве внешнего. Хоть серые, хоть белые, хоть в полоску.

Как я понимаю - речь идет о двух системах получающих внешний адрес динамически...

Что вы там собираетесь написать в конфигурации?

Сам использую OpenVPN в своей практике постоянно.

НО! Тема в статье АБСОЛЮТНО не раскрыта! Кто был на сайте OpenVPN, сможет подтвердить - лучше было бы перевести HOWTO.

Кстати, есть задача нераскрытая в данной стать и в HOWTO OpenVPN тоже: необходимо сделать на основе шлюзов (OpenVPN) полноценный VPN маршрутизатор. Это когда всем ПК во всех офисах выдаются адреса из одной подсети и все ПК видят друг-друга АБСОЛЮТНО прозрачно.

Если кто-то знает как это сделать - дайте линк на RTFM (для любой VPN ситемы).

HOWTO - про brige mode

>Что вы там собираетесь написать в конфигурации? remote myserver.dyndns.org 1194

>Да и вообще, в послдених версиях openssh есть свой vpn, так что pppd тут не нужен.

Можно поподробней? Всегда думал, что под VPN через ssh подразумевалось туннелирование (-L8080:1.1.1.1:8080)

>А вот пусть попробуют забацать vpn между только серыми адресами.

OpenVPN сервер должен иметь внешний IP. Клиенты могут иметь любые.

>Это когда всем ПК во всех офисах выдаются адреса из одной подсети и все ПК видят друг-друга АБСОЛЮТНО прозрачно.

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

Вы же сейчас не понимая последствий хотите наступить на грабли, по которым уже прошлись другие. Что есть для вас ПРОЗРАЧНОСТЬ? И главное, зачем она вам? У вас действительно есть немаршрутизируемые протоколы и вы без них жить не можите? Ну коли так, то читайте про режим bridge, который поддерживает OpenVPN. Только советую вам выделить такие компы в отдельный сегмент или VLAN. Делать bridge на всю сеть весьма плохая идея.

Про OpenVPN vs IPSec, GRE, ssh+pppd, tinc, VTun, CIPE и т.д.:

IPSec и GRE требуют чтобы сеть провайдера прозрачно пропускала протоколы ESP, AH, GRE. Увы, так бывает не всегда. IPSec ко всему прочему не любит NAT. Чтобы он заработал, надо приложить определенные усилия. GRE является только протоколом инкапсуляции, шифрования в нем нет, поэтому назвать его средством создания VPN-соединений как-то не поворачивается язык. GRE обычно используют еще с чем-то, что трафик зашифрует. ssh+pppd является частным применением и крайне редко используется. О накладных расходах уже сказали. tinc, VTun, CIPE тоже частные решения, работают в основном в Linux и боле никуда не портированы.

OpenVPN работает по любой говенной сети. Хоть по TCP, хоть по UDP, хоть даже через прокси. OpenVPN портирован на несколько разных ПОПУЛЯРНЫХ ОС и без проблем там работает, т.е. является кроссплатформенным решением. Поддерживает передачу трафика как в режиме router, так и в режиме bridge и может без проблем передавать любой сетевой трафик. Поддерживает все режимы шифрования, которые предоставляет бибилотека OpenSSL. Может работать без пароля, по паролю, используя систему сертификатов. Является открытым продуктом и любой желающий может на его базе наворотить своего чего-то, если у него руки растут из правильного места.

Естественно на шифрование надо платить снижением производительности. Да, возможно надо что-то тюнить. Однако голословно утверждать что что-то хуже только потому, что что-то лучше, по крайней мере не красиво.

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

Я считаю, что по простоте и гибкости лучше OpenVPN пока ничего не придумали. Комерческих аналогов зато пруд пруди. Называются они обычно типа "ЧЕГО_НИТО VPN SSL клиент". Хотите платить за это бабки? Флаг в руки. Вас устраивают то, чем вы сейчас пользуетесь? На здоровье. Однако вы все равно перейдете на OpenVPN, ибо это только вопрос времени.

> Я считаю, что по простоте и гибкости лучше OpenVPN пока ничего не придумали.

> Однако вы все равно перейдете на OpenVPN, ибо это только вопрос времени.

Я - не админ. Просто программер. Иногда, правда, приходится выступать в не свойственной мне роли. Типа "систему знаешь, а системщик на больничном...". Но с Вашими словами, в данном контексте, - совершенно согласен. Пол-года назад, может чуть более, пришлось вязать три сетки в одном тёмном уголке Красноярского края. Тады-то всё и понял... ;-)

> Естественно на шифрование надо платить снижением производительности. Да, возможно надо что-то тюнить. Однако голословно утверждать что что-то хуже только потому, что что-то лучше, по крайней мере не красиво.

А есть ли где-то сравнения/описания производительности, величине дополнительного трафика, требования к ширине канала у разных реализаций VPN? Особенно интересно как vpn соединение ест трафик, который не всегда бесплатный. ;)

Постановка вопроса несколько неверная. Да, VPN вносит накладные расходы. Сколько? Ну возьмите описание любого VPN-решения и увидите долю служебной информации. Только ведь не это одно является определяющим фактором. Есть еще и множество других. Они вам не интересны? Наверно да, просто вы о них не говорите.

Я считаю, что в среднем по больнице доля служебного трафика одинакова. Решающее значение на мой взгляд имеет вездеходность и возможность гибкой настройки под разные нужды и конкретные ситуации.

dh /etc/openvpn/vserver/keys/dh1024.pem

Диффи-Хеллман на стророне клиента не нужен.

>Диффи-Хеллман на стророне клиента не нужен.

Твой вариант решения проблемы с атаками типа "Man in the middle" ?

> Во-первых, все современные vpn-решения для линукса (openvpn, tinc, cipe, vtun) умеют работать поверх udp. Во-вторых, это самый правильный способ - http://sites.inka.de/~W1011/devel/tcp-tcp.html

http://barabanov.ru/arts/tcp/Tcp_over_tcp_is_not_so_bad-web.pdf

Этих док уже как грязи.

А толковой доки а-ля "создаем сервер, ждем пока наши прекрасные домашние виндовые компы подключатся, даем им динамические адреса", что-то нет (по крайней мере рабочей).

Попробовал сделать по статье. Фиг там, заверните в газетку. Прямо-таки поток негативного сознания.

Не работает. Рисует ошибку, аналогичную вот этому:

http://fixunix.com/openssl/156978-i-am-getting-tls-error-tls-handshake-failed...

на гугле можно порыться - там много аналогичных вопросов.
Рекомендуют проверить сертификаты а-ля "openssl verify -CAfile ca.crt -purpose sslserver gateway.crt" и "openssl verify -CAfile ca.crt -purpose sslclient client.crt". Проверил. Написало ОК на оба сертификата.

Вопрос аффтару: ЧТО Я ДЕЛАЮ НЕПРАВИЛЬНО? :-)

На самом деле, ошибка (видимо) вот в чем:
Аффтар создал для сервера (office-0) клиентский сертификат. Именно поэтому оно пишет ошибку. Соответственно, проверяется командочкой
"openssl verify -CAfile ca.crt -purpose sslserver office-0.crt"

которая и пишет ту же самую ошибку - насчет назначения сертификата.