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

Свет в конце тоннеля: 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. Подробнее с примерами их использования можно ознакомиться по ссылкам выше.

FreeBSD + OpenVPN tap: нид хелп

admin — Tue, 15 Feb 2011 07:19:18 +0000

Собственно, что мы имеем:
FreeBSD 7.2 + OpenVPN client
openvpn настроен на tap (Конфиг не прицнипиален, но если нужно, приложу)

ifcnofig:

    tap10: flags=8943 metric 0 mtu 1500
     ether 00:bd:ed:bf:09:0a
     Opened by PID 80904
    bridge10: flags=8843 metric 0 mtu 1500
     ether aa:fe:fa:21:82:e5
     inet 10.255.1.114 netmask 0xfffffff8 broadcast 10.255.1.119
     id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15
     maxage 20 holdcnt 6 proto rstp maxaddr 100 timeout 1200
     root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0
     member: vlan1058 flags=143
      ifmaxaddr 0 port 9 priority 128 path cost 20000
     member: tap10 flags=143
      ifmaxaddr 0 port 7 priority 128 path cost 2000000
    vlan1058: flags=8943 metric 0 mtu 1500
     options=3
     ether 00:30:48:62:97:de
     inet x.x.x.x netmask 0xfffffffc broadcast x.x.x.x
     media: Ethernet autoselect (1000baseTX )
     status: active
     vlan: 1058 parent interface: em0

netstat -rn

    Destination Gateway Flags Refs Use Netif Expire
    default x.x.x.65 UGS 0 5380 vlan10
    10.0.0.0/8 10.255.1.113 UGS 0 65951 bridge
    10.12.0.0/24 10.12.51.1 UGS 0 2303745402 em0
    10.12.4.0/24 link#4 UC 0 0 vlan12
    10.255.1.112/29 link#8 UC 0 0 bridge
    10.255.1.113 00:1c:c0:7c:a6:26 UHLW 5 19 bridge 1185
    x.x.x.x/30 link#9 UC 0 0 vlan10
    x.x.x.65 12:34:56:78:90:12 UHLW 2 248 vlan10 1137
    x.x.x.66 12:34:56:78:90:12 UHLW 1 0 lo0
    127.0.0.1 127.0.0.1 UH 0 8069771 lo0
    192.169.0.0/24 link#2 UC 0 0 em1

Яндексы пингуются, и вроде даже все замечательно, но. Трафик не ходит. Ни веб, ни что-либо иное.
tcpdump показывает странное:
на tap-интерфейсе виды и запросы и ответы (в случае пинга). На целевом узле видно только приходящие пакеты (если пакеты icmp, видно и входящие и исходящие)
на bridge видно только ответы от сервера (исходящие пакеты)
на vlan вообще ничего не видно

Разрешающие правила ipfw ситуацию не меняют ровно никак

А теперь внимание, вопрос, граждане читающие: где я накосячил?
P.S. Пробовал менять mtu на меньшее (1350), пробовал опции –fragment и –mssfix, но толку чуть – по tcpdump видно,что пинги большими пакетами ходят исправно и исправно режутся в соответствии с mtu, но tcp/udp не ходит никак. Уже даже не знаю, что думать

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

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

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

Нестандартное подключение. pptp в Linux

admin — Sun, 27 Sep 2009 14:34:34 +0000

Имеется – компьютер в локальной сети с Ubuntu 9.04, подключаемый к интернету с помощью двух vpn-соединений. первое нужно для связи с vpn-сервером провайдера, второе – для непосредственно выхода в инетернет.

Перво-наперво ставим пакеты ppp и pptp.
Затем необходимо (в моем случае) прописать необходимые маршурты к первому vpn-серверу (да, вот такие извращения…):

#!/bin/sh
route add -net 10.12.5.0/24 gw 10.12.5.1
route add -net 10.12.51.0/24 gw 10.12.5.1
route add -net 10.12.4.0/24 gw 10.12.5.1
route add -host 10.10.10.10 gw 10.12.5.1
route add -host 10.10.10.78 gw 10.12.5.1

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

Затем создаем файлик /etc/ppp/peers/vpn

$sudo -i //чтобы лишний раз не заморачиваться насчет прав
#cd /etc/ppp/peers
#touch vpn
#mcedit vpn

Содержание файла:

pty "pptp 10.12.51.226 --nolaunchpppd" //ип сервера, с которым соединяемся
user yourlogin
password "YoUrPaSsWoRd" //обязательно в кавычках!
nodeflate
nobsdcomp
noauth
require-mppe-128
mtu 1460
refuse-eap
refuse-chap
refuse-mschap

Далее открываем файлик /etc/ppp/ip-up и добавляем в конец строки:

route add -net 10.255.0.0/16 dev ppp0

Этот маршрут необходим, чтобы связаться с сервером провайдера именно через это vpn-соединение

Пробуем:

#pppd call vpn debug nodetach

Последние две опции необходимы для отладки. Наблюдаем в консоли примерно такую картину:

using channel 2
Using interface ppp0
Connect: ppp0 <--> /dev/pts/0
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x33368137> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x1 <auth chap MD5> <magic 0x36da4966>]
sent [LCP ConfAck id=0x1 <auth chap MD5> <magic 0x36da4966>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x33368137> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x33368137> <pcomp> <accomp>]
sent [LCP EchoReq id=0x0 magic=0x33368137]
rcvd [CHAP Challenge id=0x1 <f872f6df5542429b46d6cf7e89a3386c>, name = "bras8"]
sent [CHAP Response id=0x1 <ebb4965e871c49a07565b148dc2dbf29>, name = "unicorn2"]
rcvd [LCP EchoRep id=0x0 magic=0x36da4966]
rcvd [CHAP Success id=0x1 ""]
CHAP authentication succeeded
CHAP authentication succeeded
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>]
rcvd [IPCP ConfReq id=0x1 <addr 195.14.38.8>]
sent [IPCP ConfAck id=0x1 <addr 195.14.38.8>]
rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
sent [IPCP ConfReq id=0x2 <addr 0.0.0.0>]
rcvd [IPCP ConfNak id=0x2 <addr 89.178.77.182>]
sent [IPCP ConfReq id=0x3 <addr 89.178.77.182>]
rcvd [IPCP ConfAck id=0x3 <addr 89.178.77.182>]
Cannot determine ethernet address for proxy ARP
local  IP address 89.178.77.182
remote IP address 195.14.38.8
Script /etc/ppp/ip-up started (pid 4072)
Script /etc/ppp/ip-up finished (pid 4072), status = 0x0

У нас появилось новое сетевое устройство ppp0.

Пингуем vpn провайдера:

#ping 10.255.0.1

Если ответ есть, значит все прекрасно. Если нет – проверяем маршруты и настройки соединения.

Далее создаем файлик /etc/ppp/peers/internet:

pty "pptp 10.255.0.2 --nolaunchpppd" //адрес vpn-сервера провайдера
user yourlogin
password "YoUrPaSsWorD"
nodeflate
nobsdcomp
noauth
require-mppe-128
mtu 1460
refuse-eap
refuse-chap
refuse-mschap

В конец файла /etc/ppp/ip-up дописываем:

route add default dev ppp1

Соединяемся:

pppd call internet debug nodetach

Если все прошло успешно, у нас должен появится инет. Если нет – курим маршруты и настройки соединения.

теперь vpn можно поднимать двумя командами:

pppd call vpn
pppd call internet

Только прошу обратить внимание, что демон pppd требует рутовых прав