Записки на полях » network

Свет в конце тоннеля: OpenVPN + FreeBSD7

admin — Thu, 03 Mar 2011 08:33:20 +0000

Vtund всем хорош, кроме одного – в глобальных сетях его использовать трудно. А что делать, если среда дюже недружелюбная (считай – зарезано все, кроме стандартных протоколов, и ipip провесить уже не выйдет). Наш выход – VPN. Тем более что OpenVPN поможет и влан прокинуть, и данные зашифрует, и вообще, позволит создать у пользователя уверенность, что удаленный филиал находится вовсе не в другом городе, а за стенкой (где б еще такой инет взять…)

Исходные данные:
Сервер: Linux 2.6.28.2
Клиент: FreeBSD 7.2-RELEASE-p8
OpenVPN 2.1.4

Задача: Организовать подключение таким образом, чтобы клиент, и сеть за ним могли видеть локальную сеть за сервером так, будто это два рядом стоящих маршрутизатора. Собственно, настройка занимает минут пятнадцать.

На клиенте:

cd /usr/ports/security/openvpn && make install clean

/etc/rc.conf

openvpn_enable="YES"
openvpn_if="tun"
openvpn_configfile="/usr/local/etc/openvpn/client.conf"
openvpn_dir="/usr/local/etc/openvpn"

Описание директив спер отсюда и отсюда

/usr/local/etc/openvpn/client.conf

#определяет какой использовать тип устройства tun или tap.
dev tun
#Возможные значения: udp, tcp, tcp-client, tcp-server. С первыми двумя все ясно, 
#а на последних двух остановимся чуть подробнее:
#tcp-client - сам пытается установить соединение
#tcp-server - только ждет подключений
#Примечательно, что с использованием протокола udp VPN будет работать чуть быстрее, 
#чем tcp. Но в плане стабильности работы лучше выбирать tcp 
#(как показывает практика, VPN-соединение более устойчиво)
proto udp
#определяет удаленный конец туннеля. Могут использоваться записи IP и DNS.
remote 10.12.0.201
port 1194 
#Роль - клиент или сервер
client
#если OpenVPN не удалось узнать имя удаленного хоста по DNS, 
#то через указанное количество секунд попытаться переподключиться.
resolv-retry infinite
#Настройки сертификатов и безопасности
ca /usr/local/etc/openvpn/keys/ca.crt
cert /usr/local/etc/openvpn/keys/client.crt
key /usr/local/etc/openvpn/keys/client.key
tls-client
tls-auth /usr/local/etc/openvpn/keys/ta.key 1
#алгоритм хэширования
auth SHA512
#указываем алгоритм шифрования
cipher BF-CBC
ns-cert-type server
persist-key
persist-tun
#Настройки логов
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
#Уровень детализации логов
verb 3
#Маршрут на удаленную сеть, который поднимается при подключении
route 10.255.0.0 255.255.255.0

На стороне сервера:
/etc/openvpn/server.conf

 
local 10.12.0.201
port 1194
proto udp
dev tun10
 
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/server.crt
key /etc/openvpn/keys/server.key
dh /etc/openvpn/keys/dh1024.pem
#автоматически присваивает адреса всем клиентам (DHCP) 
#в указанном диапазоне с маской сети. 
#Данная опция заменяет ifconfig и может работаеть только с 
#TLS-клиентами в режиме TUN, соответственно использование 
#сертификатов обязательно. Например: server 10.3.0.0 255.255.255.0
#Подключившиеся клиенты получат адреса в диапазоне между 10.3.0.1 и 10.3.0.254.
server  10.255.1.112 255.255.255.248
#Статические маршруты, которые будут выдаваться клиенту
push "route 10.0.0.0 255.0.0.0"
push "route 92.50.243.0 255.255.255.0"
push "route 94.25.108.0 255.255.255.0"
push "route 46.8.128.0 255.255.128.0"
 
#Папка с дополнительными настройками клиента
client-config-dir ccd
#Статические маршруты на сеть за клиентом, которые поднимаются на сервере
route 10.255.1.112 255.255.255.252
route 10.12.4.0 255.255.255.0
route 10.12.5.0 255.255.255.0
route 10.12.51.0 255.255.255.0
 
client-to-client
keepalive 10 120
 
tls-server
tls-auth /etc/openvpn/keys/ta.key 0 # This file is secret
 
auth SHA512
cipher BF-CBC        # Blowfish (default)
 
max-clients 10
#Пользователь и группа, от имени которых будет запускаться процесс
user openvpn
group openvpn
 
#Не перечитывать файлы с ключами при получении SIGUSR1 или --ping-restart.
#Эта опция может быть использована совместно с --user nobody, 
#чтобы разрешить перезапуски вызываемые SIGUSR1. 
#По умолчанию, если вы понижаете привелегии демона OpenVPN, то 
#его нельзя перезапустить, так как невозможно заново прочитать защищенные файлы ключей. 
persist-key
#Не закрывать и повторно открывать устройство TUN/TAP 
#или запускать скрипты up/down при получении сигнала SIGUSR1 или перезапусков по --ping-restart.
#Сигнал SIGUSR1 схож с SIGHUP, но предоставляет более точный контроль над опциями перезапуска.
persist-tun
status /var/log/openvpn/openvpn-status.log
log /var/log/openvpn/openvpn.log
verb 3

Включаем, соединяемся… пиры друг друга пингуют. С клиента пингуется сеть за сервером, а вот наоборот – хрен. Курим гугл, находим решение:

Важное замечание, что если OpenVPN запускается в режиме server (см. комментарии п.2), то статический или динамический маршрут, даже который смотрит правильно и напрямую в интерфейс tun, ни к чему не приведет, работать не будет.
Т.к. в режиме server получается point-to-multipoint линк и именно поэтому серверу надо уже объяснять какому клиенту за ифейсом tun нужно отправлять трафик. Поэтому туннельные интерфейсы могут пинговаться, а любые подсети за OpenVPN-клиентом нет, т.к. трафик не уедет в туннель.
Это хорошо видно по tcpdump, если с OpenVPN-сервера попробовать попинговать любой адрес из подсети, которая находится ЗА OpenVPN-клиентом.
С одной стороны (со стороны OpenVPN-сервера) трафик в tun виден, а до другой стороны трафик просто не доходит, а если быть точнее, то на самом деле трафик с OpenVPN-сервера просто не отправляется.

Так что файлик /etc/openvpn/ccd/client будет примерно таким:

ifconfig-push 10.255.1.114 10.255.1.113
iroute 10.12.51.0 255.255.255.0
iroute 10.12.5.0 255.255.255.0
iroute 10.12.4.0 255.255.255.0

После этого все должно заработать. Маршруты появятся автоматически, как только установится соединение. Так же можно запускать сторонние скрипты с помощью директив up и down. Подробнее с примерами их использования можно ознакомиться по ссылкам выше.

Главное отличие VPN от VLAN

admin — Wed, 26 Jan 2011 03:44:10 +0000

На самом деле термин VLAN произошел от английского термина “виллан” ( холоп ), то есть – сеть для смердов.
А термин VPN произошел от уже от севременного “ВИП-и-Н” что означает – сеть для VIP’ов.
(с) nag,ru

Траблы с vtund

admin — Tue, 25 Jan 2011 12:30:10 +0000

Хорошая штука, но на идеологически правильной ОС есть два косяка:
1. Версия 3.0.1 требует lzo (из портов ставится влет)
2. При компиляции make install ругается:

snake@serv [vtun-3.0.1]#make install
gcc -g -O2 -c main.c
main.c: In function 'main':
main.c:63: error: 'VTUN_CONFIG_FILE' undeclared (first use in this function)
main.c:63: error: (Each undeclared identifier is reported only once
main.c:63: error: for each function it appears in.)
main.c: In function 'write_pid':
main.c:217: error: 'VTUN_PID_FILE' undeclared (first use in this function)
*** Error code 1

Первое лечится отключением lzo:

./configure --disable-lzo

Второе – использованием gmake (кстати нечто похожее было при установке старгайзера:

gmake install

Делаем по-взрослому (изучаем vlan`ы)

admin — Thu, 11 Mar 2010 08:00:45 +0000

Первый раз с самим понятием вланов (virtual LAN, VLAN) я столкнулся, проживая в студенческом общежитии (как будто я там сейчас не живу – прим. авт). Универ после ремонта разродился на нормальную ЛВС – с розетками в каждой комнате, коммутационными шкафами на лестничных клетках и 48-портовыми д-линками на этаж. На каждое общежитие студгородка было выделено по 2 влана, что добавило геморроя в настройке, но позволило избавиться от лишних бродкастов (с другой стороны, всякие VypressChat уже не работали). Сама идея очень даже неплоха – пользователи отделяются друг от друга на канальном уровне, можно крутить разные подсети на одном коммутаторе и прочие плюшки.

Интернет в общаге раздается весьма своеобразно – через два сервера. На одном крутится две дсл, на другом – еще три. Модемы подключены напрямую, т.е. в одном сервере стоит три сетевушки, во втором – четыре. Это накладывает существенные ограничения во-первых на железо (найти плату с 3 и более PCI-разъемами сложновато), а во-вторых на масштабируемость – добавлять новые сетевухи это не наш метод . Т.к. под рукой совершенно случайно оказался управляемый DES-1226G с поддержкой вланов, решено было через этот самый коммутатор подключать модемы, оставив на серверах по две сетевушки – на вход и на выход. На “входящей”, соответственно висели интерфейсы общежитских сетей, на “выходящей” – вланы модемов.
Создается влан-интерфейс чрезвычайно просто:

snake@snake [snake]#ifconfig vlan1692 create vlan 1692 vlandev em1 inet 192.169.2.2 netmask 255.255.255.0

Здесь:
vlan1692 – имя интерфейса
vlan 1692 – так называемый тэг влана (если мы собираемся принимать на этом интерфейсе только тэгированный трафик, что и требуется)
vlandev em1 – указывает родительский интерфейс (транк) на котором и будет висеть влан
далее идет обычная настройка – ip, маска и т.д.
Чтобы изменения сохранились после перезагрузки, в rc.conf нужно добавить следующие строки:

snake@snake [snake]#cat /etc/rc.conf
hostname="snake.hostel5.ru"
ifconfig_em0="inet 10.1.0.1 netmask 255.255.255.0"
cloned_interfaces="vlan1205 vlan1690 vlan1691 vlan1692 vlan1693 vlan1694 vlan1695"
ifconfig_vlan1205="inet 10.12.5.254 netmask 255.255.255.0 vlan 1205 vlandev em0"
ifconfig_vlan1690="inet 192.169.0.2 netmask 255.255.255.0 vlan 1690 vlandev em1"
ifconfig_vlan1691="inet 192.169.1.2 netmask 255.255.255.0 vlan 1691 vlandev em1"
ifconfig_vlan1692="inet 192.169.2.2 netmask 255.255.255.0 vlan 1692 vlandev em1"
ifconfig_vlan1693="inet 192.169.3.2 netmask 255.255.255.0 vlan 1693 vlandev em1"
ifconfig_vlan1694="inet 192.169.4.2 netmask 255.255.255.0 vlan 1694 vlandev em1"
ifconfig_vlan1695="inet 192.169.5.2 netmask 255.255.255.0 vlan 1695 vlandev em1"

В нашем случае создается 7 vlan-интерфейсов – один на “входящей” сетевушке – для общежитской сети, и еще 6 на “выходящей” – часть из них используется для связи с модемами, часть – просто для мониторинга и управления.

Удалить влан интерфейс:

snake@snake [snake]#ifconfig vlan1692 destroy

Не забываем настроить соответствующим образом порты коммутатора – порт, к которому подключается “выходящая” сетевая карта сервера, должен пропускать только тэгированный трафик, порты, к которым подключены модемы – нетэгированный (потому как модемы в большинстве своем про всякую экзотику типа vlan слыхом не слыхивали), причем PVID порта должен совпадать с номером нужного влана (а у нас длинк, к слову. у других производителей все может быть совсем по другому).
Приведу простой пример – “выход” сервера подключен к 10 порту коммутатора. Модемы – соответственно к 11,12 и 13 портам. На 10 порту прописываются соответствующие вланы (для каждого модема отдельный, как мы помним) – все тэгированные, PVID не столь важен, потому что трафик будет пропускаться только тэгированный (от сервера либо с другого порта коммутатора).
На портах, к которым подключены модемы (11,12 и 13) прописываем по влану с опцией untag, и назначаем этим портам PVID, соответствующий номеру влана – таким образом весь нетэгированный трафик на этом порту будет считаться трафиком данного влана.
Если все настроено правильно – модемы должны пинговаться (если правильно настроены ип), и pppoe должен нормально подниматься. Если нет – смотрим, где и что недонастроили (например, интерфейс в настройках mpd).

Всяческие замечания, предложения и критика приветствуются.