LINUX.ORG.RU
ФорумAdmin

OpenVPN Ubuntu Server + OpenVPN Windows Vista


0

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] - Целевая локалка короче :) | [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

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

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

VitalkaDrug ★★
()

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

nnz ★★★★
()
Ответ на: комментарий от VitalkaDrug

Форвард пакетов работает, т.к. сервер является интернет-шлюзом для локальной сети. Правила про 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 

devilev
() автор топика
Ответ на: комментарий от nnz

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

push "route 10.0.0.0 255.0.0.0"
Как я понял этого достаточно... К тому же таблицы роутинга вроде бы как верны. Или я ошибаюсь?

devilev
() автор топика
Ответ на: комментарий от devilev

># Правильно ли будет добавить вот такое?
>$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

nnz ★★★★
()
Ответ на: комментарий от devilev

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

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

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


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

nnz ★★★★
()
Ответ на: комментарий от nnz

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

devilev
() автор топика
Ответ на: комментарий от nnz

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

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

devilev
() автор топика
Ответ на: комментарий от devilev

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

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

nnz ★★★★
()
Ответ на: комментарий от nnz

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

client-config-dir /etc/openvpn/ccd

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

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

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

/etc/init.d/openvpn restart
Затем приконнектился вновь, потом вновь route -n, и ... ничего не изменилось, аналогично с картиной в целом.

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

devilev
() автор топика
Ответ на: комментарий от devilev

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

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

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

nnz ★★★★
()
Ответ на: комментарий от nnz

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

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

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

devilev
() автор топика
Ответ на: комментарий от devilev

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

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

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

nnz ★★★★
()
Ответ на: комментарий от nnz

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

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

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.

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

devilev
() автор топика
Ответ на: комментарий от devilev

>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 не трогал? Постарайся определить, какое именно твое действие привело к изменению маски. Во всяком случае, мои рекомендации к этому не должны приводить.

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

nnz ★★★★
()
Ответ на: комментарий от nnz

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

у клиента:
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

devilev
() автор топика
Ответ на: комментарий от devilev

>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

nnz ★★★★
()
Ответ на: комментарий от nnz

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

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

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

devilev
() автор топика
Ответ на: комментарий от devilev

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

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

nnz ★★★★
()
Ответ на: комментарий от 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-сервер
В сети 192.168.1.0, на целевом клиенте:
# Локалка:
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 идут нормально;

devilev
() автор топика
Ответ на: комментарий от devilev

Сейчас внимательно посмотрел на маски подесетей
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

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

nnz ★★★★
()
Ответ на: комментарий от nnz

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

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

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

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

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

devilev
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.