OpenVPN Ubuntu Server + OpenVPN Windows Vista

Проверьте разрешен ли форвард пакетов на сервере и настройки фаервола для пропуска трафика между локальной сетью и tun-интерфейсом. Кстати, OpenVPN не использует GRE-протокол, поэтому правила для него в вашем фильтре бесполезны.

man openvpn на предмет client-config-dir и iroute.
Вопрос классический и древний как мир.

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

А вот разрешен ли пропуск трафика между tun и локальной сетью - вопрос интересный. Особенно интересно как это записать. :)

TUN_IFACE="tun0"
TUN_IP="???"
LAN_IP="10.0.0.201"
LAN_IFACE="eth1"

# Вот такая строка у меня уже есть
$IPATBLES -A FORWARD -i $LAN_IFACE -j ACCEPT

# Правильно ли будет добавить вот такое?
$IPATBLES -A FORWARD -i $TUN_IFACE -j ACCEPT

#И еще не совсем понятно, какой адрес у VPN-сервера, чтобы прописать его в цепочку OUTPUT вот так:
$IPTABLES -A OUTPUT -p ALL -s $TUN_IP -j ACCEPT 

man openvpn на предмет client-config-dir и iroute ясного ответа не дали. По сути в конфиге есть параметр

push "route 10.0.0.0 255.0.0.0"

># Правильно ли будет добавить вот такое?
>$IPATBLES -A FORWARD -i $TUN_IFACE -j ACCEPT

Правильно (не считая IPATBLES). Можно еще добавить
$IPTABLES -A FORWARD -o $TUN_IFACE -j ACCEPT

Хотя более корректно имхо будет
$IPTABLES -A FORWARD -i $LAN_IFACE -o $TUN_IFACE -j ACCEPT
$IPTABLES -A FORWARD -o $LAN_IFACE -i $TUN_IFACE -j ACCEPT

>#И еще не совсем понятно, какой адрес у VPN-сервера, чтобы прописать его в цепочку OUTPUT вот так:
>$IPTABLES -A OUTPUT -p ALL -s $TUN_IP -j ACCEPT

Обычно правильный адрес указывается после слова inet в выводе ip ad sh dev tun0.
Но в данном случае имхо достаточно
$IPTABLES -A OUTPUT -o $TUN_IFACE -j ACCEPT

>Как я понял этого достаточно...

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

>К тому же таблицы роутинга вроде бы как верны. Или я ошибаюсь?

Я видел только таблицу роутинга на клиенте. В то время как, судя по конфигам, проблема ожидается с таблицей сервера.

Добавил, не помогло. Но думаю лишним тоже не будет. :)

route -n на сервере:

10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
193.222.191.76  0.0.0.0         255.255.255.252 U     0      0        0 eth0
10.8.0.0        10.8.0.2        255.255.255.248 UG    0      0        0 tun0
10.0.0.0        0.0.0.0         255.0.0.0       U     0      0        0 eth1
0.0.0.0         193.222.ххх.ххх 0.0.0.0         UG    100    0        0 eth0

Что странно - не меняется при подключении клиента. Подскажите, что не так? Моск кипит :)

Что-что. Конфиги не так написаны.
Я ж тебе говорил — нигде у тебя в конфигах не написано, какую сеть роутит клиент. Соответственно сервер не прописывает маршрут и поэтому не знает, куда отправлять ответы на пакеты из 192.168.1.0/24.

Создавай в client-config-dir на серваке файл с именем, совпадающим с common name клиента, и пиши в него
iroute 192.168.1.0 255.255.255.0

Если я все правильно понял, то в конфиг сервера я добавил:

client-config-dir /etc/openvpn/ccd

в этом каталоге я создал целых три файла: VPN, clientVPN, client1

Это именно те варианты, которые могли бы быть common name клиента. А что это именно, CN в сертификате, или имя которое выдает клиент OpenVPN на висте в графе «connected to:» ... я не до конца понял.

После этого отключил клиента, а на сервере сделал

/etc/init.d/openvpn restart

Пересмотрел google, man и понял, что ничего не понял. :)

Видимо, не угадал с именем.

Чтобы точно узнать common name подключенного клиента (CN его сертификата), можно
1. Послать процессу сервера SIGUSR2 и посмотреть /var/log/messages
2. Добавить в конфиг сервера «status имя_файла» и посмотреть этот файл после перезапуска.
3. Добавить в конфиг сервера «management localhost порт», после перезапуска подсоединиться к этому порту через netcat и скомандовать status.

Все эти три метода дадут в числе прочих данных OpenVPN CLIENT LIST. В первом столбце указывается CN клиента.

Вот шапка сертификата клиента:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2 (0x2)
        Signature Algorithm: xxxxxxxxxxxxxxxxxxxxxxx
        <1>Issuer: C=RU, ST=HMAO, L=Surgut, O=FGUP, OU=VPN, CN=VPN/emailAddress=info@linuxsurgut.ru
        Validity
            Not Before: Oct 17 11:00:29 2009 GMT
            Not After : Oct 15 11:00:29 2019 GMT
        <2>Subject: C=RU, ST=Surgut, L=Surgut, O=Home, OU=Home, CN=clientVPN/emailAddress=info@linuxsurgut.ru

Как я понимаю, у меня CN=clientVPN, это то, что я вводил при создании сертификата.

Причем в /etc/openvpn/log/openvpn.log вот это:

Tue Oct 27 23:04:02 2009 clientVPN/188.x.x.x:x OPTIONS IMPORT: reading client specific options from: /etc/openvpn/ccd/clientVPN

Дает понять, что клиентские настройки из /etc/openvpn/ccd/clientVPN таки прочитались.

Значит дело не в неверном common name клиента...

Так же прописываются internal route, благодоря которым, как я понял, осуществляется некий внутренний роутинг в OpenVPN.

Tue Oct 27 23:04:00 2009 188.x.x.x:x TLS: Initial packet from 188.x.x.x:x, sid=141d9498 aa7d3c8a
Tue Oct 27 23:04:02 2009 188.x.x.x:x VERIFY OK: ...
Tue Oct 27 23:04:02 2009 188.x.x.x:x VERIFY OK: ... 
Tue Oct 27 23:04:02 2009 188.x.x.x:x Data Channel Encrypt: xxx
Tue Oct 27 23:04:02 2009 188.x.x.x:x Data Channel Encrypt: xxx
Tue Oct 27 23:04:02 2009 188.x.x.x:x Data Channel Decrypt: xxx
Tue Oct 27 23:04:02 2009 188.x.x.x:x Data Channel Decrypt: xxx
Tue Oct 27 23:04:02 2009 188.x.x.x:x Control Channel: xxx
Tue Oct 27 23:04:02 2009 188.x.x.x:x [clientVPN] Peer Connection Initiated with 188.x.x.x:x
Tue Oct 27 23:04:02 2009 clientVPN/188.x.x.x:x OPTIONS IMPORT: reading client specific options from: /etc/openvpn/ccd/clientVPN
Tue Oct 27 23:04:02 2009 clientVPN/188.x.x.x:x MULTI: Learn: 10.8.0.6 -> clientVPN/188.x.x.x:x
Tue Oct 27 23:04:02 2009 clientVPN/188.x.x.x:x MULTI: primary virtual IP for clientVPN/188.x.x.x:x: 10.8.0.6
Tue Oct 27 23:04:02 2009 clientVPN/188.x.x.x:x MULTI: internal route 192.168.1.0/24 -> clientVPN/188.x.x.x:x
Tue Oct 27 23:04:02 2009 clientVPN/188.x.x.x:x MULTI: Learn: 192.168.1.0/24 -> clientVPN/188.x.x.x:x
Tue Oct 27 23:04:04 2009 clientVPN/188.x.x.x:x PUSH: Received control message: 'PUSH_REQUEST'
Tue Oct 27 23:04:04 2009 clientVPN/188.x.x.x:x SENT CONTROL [clientVPN]: 'PUSH_REPLY,route 10.0.0.0 255.0.0.0,route 10.8.0.0 255.255.255.248,topology n

Может прописать маршруты в ручную? Правда я читал, что это не помогает. Да и прописывать для каждого клиента путь вручную - не есть истинный путь Джедая, и не ведет на светлую сторону силы. :)

Да, CN clientVPN правильный.

Попробуй добавить в конфиг сервера
route 192.168.1.0 255.255.255.0

iroute в ccd/clientVPN не трогай.

Добавил. Вот что изменилось:

На клиенте, вместо:

10.8.0.0    255.255.255.0         10.8.0.5         10.8.0.6     30

Теперь вот так:

10.8.0.0    255.255.255.248       10.8.0.5         10.8.0.6     30

Ну а на сервере добавился роутинг на 192.168.1.0 (# route -n):

10.8.0.2        0.0.0.0         255.255.255.255 UH    0      0        0 tun0
193.222.191.76  0.0.0.0         255.255.255.252 U     0      0        0 eth0
10.8.0.0        10.8.0.2        255.255.255.248 UG    0      0        0 tun0
192.168.1.0     10.8.0.2        255.255.255.0   UG    0      0        0 tun0
10.0.0.0        0.0.0.0         255.0.0.0       U     0      0        0 eth1
0.0.0.0         193.222.191.77  0.0.0.0         UG    100    0        0 eth0

Ping'ов нет. От клиента 192.168.1.3/255.255.255.0 (в локалке клиента), и 10.8.0.6/255.255.255.252 (VPN) не могу достучаться до 10.8.0.1, 10.0.0.201 (ну до локалки за сервером в общем), так же как и от сервера до клиента.

Глухо, как в танке. Снифер wireshark на клиенте рисует вот так:

1	0.000000	00:ff:71:0b:6c:10	Broadcast	ARP	Who has 10.8.0.5?  Tell 10.8.0.6
2	0.000025	00:ff:72:0b:6c:10	00:ff:71:0b:6c:10	ARP	10.8.0.5 is at 00:ff:72:0b:6c:10	
...
19	299.029205	10.8.0.6	10.0.0.200	ICMP	Echo (ping) request

Он же по идее должен на сервер VPN ломиться? Но опять же, 10.8.0.1 не пингуется... Полтергейст, не иначе.

Еще раз про iptables. На итого было добавлено:

-A FORWARD -i eth1 -o tun0 -j ACCEPT
-A FORWARD -i tun0 -o eth1 -j ACCEPT
# tcp_packets и udp_packets - внутренние цепочки INPUT для UDP и TCP
-A udp_packets -p udp -m udp --dport 1194 -j ACCEPT
-A tcp_packets -p tcp -m tcp --dport 1194 -j allowed
-A OUTPUT -o tun0 -j ACCEPT

Попытался было добавить "-A OUTPUT -s tun0 -j ACCEPT", но iptables странно как-то заругалось:

iptables v1.4.1.1: host/network `tun0' not found
Try `iptables -h' or 'iptables --help' for more information.

Неужели руки-таки кривые?

>10.8.0.0 255.255.255.248 10.8.0.5 10.8.0.6 30
>10.8.0.0 10.8.0.2 255.255.255.248 UG 0 0 0 tun0

Так быть не должно. Директиву server не трогал? Постарайся определить, какое именно твое действие привело к изменению маски. Во всяком случае, мои рекомендации к этому не должны приводить.

В остальном маршруты добавились вроде как верно. Поэтому есть подозрение, что проблема в висте. С сервера клиент пингуется? А из подсети сервера?

Это был какой-то глюк. После рестарта всей системы, роутинг встал на место.

у клиента:
10.8.0.0 255.255.255.0 10.8.0.5 10.8.0.6 30

у сервера:
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0

С клиента пингов нет. На WinXP с аналогичным конфигом картина не меняется. C сервера, клиент (10.8.0.6) так же не пингуется, ну и сетка за ним соответственно не видна.

Сервер сам себя должен пинговать?

# ping 10.8.0.1
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
ping: sendmsg: Operation not permitted

>ping: sendmsg: Operation not permitted

Пинг запрещен фаерволом.
iptables -I INPUT -i lo -j ACCEPT
iptables -I OUTPUT -o lo -j ACCEPT

>С клиента пингов нет
iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p icmp -j ACCEPT
iptables -I OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -p icmp -j ACCEPT

Пинги пошли внутри VPN! Я даже и не думал, что надо разрешать icmp для локального интерфейса! Это гениально и так просто! :)

Пинги есть от сервера до клиента по адресам VPN (10.8.0.1 <-> 10.8.0.6). Локалку 10.0.0.х с клиента все еще не видно.

ps: nnz, моей благодарности лично Вам просто нет предела! :)

Ну что, будем разбираться с оставшимися проблемами.

Сервер и клиент являются дефолтными шлюзами для своих подсетей?

В сети 10.0.0.0/255.0.0.0 на всех машинах:

ip: 10.0.0.xxx
mask: 255.0.0.0
gateway: 10.0.0.201
dns: 10.0.0.201

# При этом шлюз 10.0.0.201 - это и VPN-сервер

# Локалка:
ip: 192.168.1.3
mask: 255.255.255.0
gateway: 192.168.1.1
dns: 192.168.1.1

# При этом 192.168.1.1 - ADSL Acorp W422G настроенный роутером

# VPN (выдается при подключении)
ip: 10.8.0.6
mask: 255.255.255.252
gateway: -пусто-
dns: -пусто-

Тоесть для подсети 10.0.0.0 шлюз по-умолчанию 10.0.0.201, а для 192.168.1.0 шлюз 192.168.1.1. Но для второй локалки (за клиентом) так и должно быть. Вся эта локалка не обязательно должна ходить на удаленную. Главное чтобы клиент ходил.

Cегодня ситауция по пингам такая:

Пинги от клиента 192.168.1.3:
1. До 10.8.0.1 идут;
2. До 10.0.0.201 идут;
3. До 10.0.0.200 не идут;
Пинги от сервера 10.0.0.201:
1. До 10.8.0.1 идут;
2. До 192.168.1.3 не идут;
3. Ну и до своей локалки 10.0.0.200 идут нормально;

Сейчас внимательно посмотрел на маски подесетей
10.0.0.0/255.0.0.0 — локалка сервера
10.8.0.0/255.255.255.0 — впн

Т.е. локальная подсеть сервера включает подсеть впна.
Это не есть правильно. Меняй подсеть впна на что-нибудь более вменяемое, например, 192.168.10.0/255.255.255.0 или там 172.16.0.0/255.240.0.0

А из клиентской подсети пинги до сервера и дальше ходить и не будут, при таком-то дефолтном шлюзе. Если надо, чтобы ходили — либу пускай весь трафик через клиента, либо прописывай на каждом нужном компе маршруты до подсетей впна и сервера через клиента. Ну это понятно (надеюсь).

Маски заменил. Теперь VPN 192.168.10.0/255.255.255.0, и конечно же все запело сразу после реконнекта. :) Заработал даже файловый доступ

А из клиентской подсети пинги до сервера и дальше ходить и не будут

В рамках данного решения этого не надо. :)

Огромное спасибо лично nnz!!!

Полный HOW-TO опубликую в ближайшее время в своем блоге.