OpenVPN Ubuntu Server + OpenVPN Windows Vista

[devilev]

Поиск по форуму понятного для меня ответа на мой вопрос не дал, поэтому создаю новую тему.

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

[10.0.0.199/255.0.0.0] - Локалка, юзер1
[10.0.0.200/255.0.0.0] - Локалка, сервер1
         |
[10.0.0.0/255.0.0.0] - Целевая локалка короче
         |
[10.0.0.201/255.0.0.0] - Шлюз в инет на Ubuntu Server 9.04, eth0
[10.8.0.0/255.255.255.0] - Это, как я понял, VPN-сетка
[193.222.ххх.ххх] - Шлюз в инет на Ubuntu Server 9.04, eth1
         |
[ip_провайдера] - Тут ADSL-маршрутизатор. С ним 100% все ОК, и ничего настраивать не надо.
         |
[192.168.1.0/255.255.255.0] - Локалка у клиента
         |
[192.168.1.3/255.255.255.0] - Клиент на Windows Vista + OpenVPN 2.1-RC7

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

Но пинг от 192.168.1.3 до, например, 10.0.0.201 или 10.0.0.199 не идет, как в принципе и обратно.

Конфиг на сервере, Ubuntu Server 9.04:

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

port 1194

proto udp
dev tun

ca "/etc/openvpn/keys/ca.crt"
cert "/etc/openvpn/keys/server.crt"
key "/etc/openvpn/keys/server.key" # Этот файл хранить в секрете!

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

# включаем TLS аутификацию
tls-server
# указываем tls-ключ, и указываем 0 для сервера, а 1 для клиента
tls-auth "/etc/openvpn/keys/ta.key" 0
# таймаут до реконекта tls-timeout 120
auth MD5

#задаем IP-адрес сервера и маску подсети
server 10.8.0.0 255.255.255.0

#задаем МАРШРУТ который передаём клиенту
# и маску подсети для того чтобы он "видел"
# сеть за OpenVPN сервером (сеть 192.168.1.0/24)
push "route 10.0.0.0 255.0.0.0"

ifconfig-pool-persist "/etc/openvpn/config/ipp.txt"

# удерживать соединение (полезно при работе через nat, proxy и т.п.)
keepalive 10 120

# включаем шифрацию пакетов
cipher BF-CBC

# включить сжатие
comp-lzo

# максимум клиентов
max-clients 5

persist-key

persist-tun

# клиенты могут "видеть" друг друга
client-to-client

status "/etc/openvpn/log/openvpn-status.log"

log "/etc/openvpn/log/openvpn.log"
log-append "/etc/openvpn/log/openvpn.log"

# уровень детализации отчетов
verb 3

Вот это добавил к своему скрипту iptables:

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

-A INPUT -p gre -s 0/0 -j ACCEPT
-A INPUT -p 47 -s 0/0 -j ACCEPT
-A OUTPUT -p gre -m state --state RELATED, ESTABLISHED -j ACCEPT
-A udp_packets -p UDP -s 0/0 --destination-port 1194 -j ACCEPT
udp_packets - цепочка проверки пакетов udp, ничего сверхествественного

Конфиг на клиенте, Windows Vista Ultimate:

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

client

dev tun

proto udp

# IP-адрес и порт сервера OpenVPN)
remote 193.222.xxx.xxx 1194

resolv-retry infinite

nobind

persist-key
persist-tun

ca "C:Program FilesOpenVPNconfigca.crt"
cert "C:Program FilesOpenVPNconfigclient1.crt"
key "C:Program FilesOpenVPNconfigclient1.key"

tls-client
tls-auth "C:Program FilesOpenVPNconfig a.key" 1
auth MD5

ns-cert-type server
comp-lzo
verb 3


route print на клиенте до подключения:

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
          0.0.0.0          0.0.0.0      192.168.1.1      192.168.1.3     25
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      192.168.1.0    255.255.255.0         On-link       192.168.1.3    281
      192.168.1.0    255.255.255.0         On-link      192.168.1.99    276
      192.168.1.3  255.255.255.255         On-link       192.168.1.3    281
     192.168.1.99  255.255.255.255         On-link      192.168.1.99    276
    192.168.1.255  255.255.255.255         On-link       192.168.1.3    281
    192.168.1.255  255.255.255.255         On-link      192.168.1.99    276
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link       192.168.1.3    301
        224.0.0.0        240.0.0.0         On-link      192.168.1.99    277
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link       192.168.1.3    281
  255.255.255.255  255.255.255.255         On-link      192.168.1.99    276


route print на клиенте после подключения:

(Нажмите, чтобы показать/скрыть)

Код: [Выделить]

IPv4 таблица маршрута
===========================================================================
Активные маршруты:
Сетевой адрес           Маска сети      Адрес шлюза       Интерфейс  Метрика
          0.0.0.0          0.0.0.0      192.168.1.1      192.168.1.3     25
         10.0.0.0        255.0.0.0         10.8.0.5         10.8.0.6     30
         10.8.0.0    255.255.255.0         10.8.0.5         10.8.0.6     30
         10.8.0.4  255.255.255.252         On-link          10.8.0.6    286
         10.8.0.6  255.255.255.255         On-link          10.8.0.6    286
         10.8.0.7  255.255.255.255         On-link          10.8.0.6    286
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      192.168.1.0    255.255.255.0         On-link       192.168.1.3    281
      192.168.1.0    255.255.255.0         On-link      192.168.1.99    276
      192.168.1.3  255.255.255.255         On-link       192.168.1.3    281
     192.168.1.99  255.255.255.255         On-link      192.168.1.99    276
    192.168.1.255  255.255.255.255         On-link       192.168.1.3    281
    192.168.1.255  255.255.255.255         On-link      192.168.1.99    276
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link       192.168.1.3    301
        224.0.0.0        240.0.0.0         On-link      192.168.1.99    277
        224.0.0.0        240.0.0.0         On-link          10.8.0.6    286
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link       192.168.1.3    281
  255.255.255.255  255.255.255.255         On-link      192.168.1.99    276
  255.255.255.255  255.255.255.255         On-link          10.8.0.6    286


Вопрос: Что я делаю не так? Вроде бы все говорит о том, что клиент приконнектился к локалке и теперь может с ней полноценно работать, а на деле даже пингов нет...

[Vitaliy.Golubev]

Вопрос актуален. Проблема та же. Моежт кто-нибудь подскажет ресурс, на котором могут подсказать в данной проблеме?

[devilev]

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

Создал такую же тему здесь, если кому интересно.

[Tokh]

Ни ответа, ни предположений. Да. Скромный опыт - тоже да.

Виста пока прошла мимо меня и моего офиса. Одному человеку со Свистой настраивал OpenVPN. Конфиг клиента обкатывал на ХР - всё хорошо. Тот же конфиг клиента на Свисте - не прописывает у себя маршруты. Это видно в логах OpenVPN, детализация логов вроде 5, но может было 3, надо пробовать. Тупо сделал батник добавляющий маршруты, убирающий маршруты... Подымать службу не было необходимости - желание человека со Свистой.

Можно "было п у ей" прописать постоянные маршруты, но забил по желанию клиента. Да и всё одно ведь - руками запускает.

[devilev]

Очень кстати у меня под рукой оказалась машина под управлением оффтопик-хп сп3.

Процесс установки и конфиг OpenVPN, условия коннекта, брандмауэр клиента : 1 в 1. Поведение, к сожалению, тоже. Так что не в версии оффтопика дело...

[Tokh]

Вот так нельзя:

(Нажмите, чтобы показать/скрыть)

в конфиге server 10.8.0.0 255.255.255.0
и
[10.0.0.199/255.0.0.0] - Локалка, юзер1
[10.0.0.200/255.0.0.0] - Локалка, сервер1
         |
[10.0.0.0/255.0.0.0] - Целевая локалка короче Smiley
         |
[10.0.0.201/255.0.0.0] - Шлюз в инет на Ubuntu Server 9.04, eth0
[10.8.0.0/255.255.255.0] - Это, как я понял, VPN-сетка

Должны быть разные подсетки у локалки1, у локалки 2 и у VPN туннеля. Если это не так, но система каналов работает, то значит работает какая-то "хитрая" надстройка как у M$-Вин, которая прячет этот факт. Если представить себе что есть адрес шлюза и интерфейс для уходящих пакетов, попытаться на шлюзе составить нужные route комманды, то должно стать понятно, что так нельзя. Возникает неоднзначность. Адреса туннеля здесь целиком попадают в подсетку локалки 1 - конфликт, адреса из одной подсетки одновременно за разными адаптерами - за tun адаптером и за физическим локальным. Т.е. вопрос в маршрутах на сервере с OpenVPN и следом нужно менять адреса или маски сетей для решения вопроса.

Второе - tun интерфейсы получают нужные адреса? Это видно по ipconfig и ifconfig? Если да, то приконнектился, если нет - нет и есть ещё какaя-то вторая нестыковка.

P.S. Вообще тут иногда может помочь самый простой сниффер и пингование. На всех машинах, в отношении всех остальных. Выявляется где исчезает пакет, и где последний раз он есть, через какие интерфейсы система его отправляет. Тем самым можно понять в какой точке, на какой машине проблема. Сниффер для Пенды - Wireshark знаю.

[yuristep]

Я обычно в таких случаях иду по порядку:
1 - (вон те кусочки из iptables - временно нафиг-с)
2 - ложим и клиента и сервер
3 - поднимаем сервер, смотрим как у него с интефейсом ВПН, адресом, маршрутизацией
4 - поднимаем клиента, проверяем - установил ли соединение, получил ли сетевой адрес, добавил ли новый маршрут ... после чего пингуем ип нашего ВПН сервера
5 - только ТЕПЕРЬ шаманим с iptables и маршрутами между нашими подсетями...

Теперь собственно по Вашему конфигу:
push "route 10.0.0.0 255.0.0.0" - че-то "кривовато" будет. я бы прменял на следующие две строки:
push "route 10.0.0.0 255.255.255.0"
push "route-gateway ip-VPN-адрес_сервера"

[devilev]

Я обычно в таких случаях иду по порядку:
1 - (вон те кусочки из iptables - временно нафиг-с)
2 - ложим и клиента и сервер
3 - поднимаем сервер, смотрим как у него с интефейсом ВПН, адресом, маршрутизацией
4 - поднимаем клиента, проверяем - установил ли соединение, получил ли сетевой адрес, добавил ли новый маршрут ... после чего пингуем ип нашего ВПН сервера
5 - только ТЕПЕРЬ шаманим с iptables и маршрутами между нашими подсетями...

Дело в том, что iptables уже поднято.

Теперь собственно по Вашему конфигу:
push "route 10.0.0.0 255.0.0.0" - че-то "кривовато" будет. я бы прменял на следующие две строки:
push "route 10.0.0.0 255.255.255.0"
push "route-gateway ip-VPN-адрес_сервера"

Сделал так. Теперь при коннекте в логе клиента вот так:

Код: [Выделить]

TEST ROUTES: 0/2 succeeded len=2 ret=0 a=0 u/d=up
Wed Oct 28 16:40:32 2009 Route: Waiting for TUN/TAP interface to come up...
Wed Oct 28 16:40:33 2009 TEST ROUTES: 0/2 succeeded len=2 ret=0 a=0 u/d=upТак раз 30, но чуть позже коннект происходит. Пингов нет.