Как обеспечить общий доступ к файлам клиентов через OpenVPN, поднятом на Debian 6.0?

Question

[cskamsk]

Доброго вечера!

Столкнулся с проблемой настройки VPN сервера на поднятом Debian (digitalocean, если важно). Задача поставлена была простая. Общий доступ к устройствам на Android, Windows и Mac через OpenVPN, а именно - использование съемных носителей, жестких дисков и SSD внутри VPN без лишней головной боли.

Итого имеем: стабильный работающий канал, устройства по факту независимы, пинг на них, а также на DHCP самого сервера не проходит, при том, что доступ в интернет и SSH до сервера проходит.

Листинг содержания конфигураций и таблиц ниже:
server.conf

local a.b.c.d
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS 8.8.8.8"
push "dhcp-option DNS 8.8.4.4"

tls-auth ta.key 0
port 5000
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem

server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
client-config-dir ccd
route 10.8.0.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"
client-to-client

comp-lzo
keepalive 10 120
persist-key
persist-tun
status openvpn-status.log
verb 3

openvpn-status.log
Всего имеем 3 сертификата vpn.windows, vpn.home, vpn.android

OpenVPN CLIENT LIST
Updated,Wed Apr 30 13:45:18 2014
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
vpn.home,a.b.c.d:1026,1328776,3005450,Wed Apr 30 13:33:14 2014
vpn.windows,a.b.c.d:1025,2444386,1602231,Wed Apr 30 13:20:57 2014
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
10.8.0.0/24,vpn.home,a.b.c.d5:1026,Wed Apr 30 13:33:15 2014
10.8.0.14,vpn.windows,a.b.c.d:1025,Wed Apr 30 13:45:17 2014
10.8.0.6,vpn.home,a.b.c.d5:1026,Wed Apr 30 13:45:16 2014
10.8.0.13C,vpn.home,a.b.c.d:1026,Wed Apr 30 13:45:17 2014
GLOBAL STATS
Max bcast/mcast queue length,1
END

clientconfig.ovpn

remote a.b.c.d 5000
client
dev tun
ping 10
comp-lzo
proto udp
tls-client
tls-auth ta.key 1
remote-cert-tls server
pkcs12 vpn.home.p12
verb 3
pull

Также в /etc/openvpn/ccd имеются два файла с именами сертификатов и с таким содержимым
iroute 10.8.0.0 255.255.255.0

В качестве клиента на устройствах работает Viscosity и OpenVPN. Заранее спасибо за ответы.

Answer 1

[Panfilov]

Все еще есть необходимость?

Comments

[cskamsk]

Да, все еще есть

[Panfilov]

>> пинг на них, а также на DHCP самого сервера не проходит
Тут первым делом необходимо, чтобы пинг проходил, да и вообще, чтобы помех для соединения от клиента к серверу на Debian не было.
Смотреть iptables, открыть порт udp 5000 (по умолчанию для openvpn 1194, но в конфиге указан 5000)

Далее, посмотрите /var/log/openvpn.log в момент соединения, возможно клиентские ключи/сертификаты необходимо переложить в /etc/openvpn/ccd, т.к. эту папку вы указали в конфиге (у меня ключи/сертификаты лежат в ней - клиенты подсоединяются)

Далее, возможно вам понадобится опция duplicate-cn в конфиге сервера (если сертификаты не индивидуальные на каждого клиента)

На этом этапе важно, чтобы клиент подключился и получил ip-адрес от сервера, далее можно уже настроить нужную маршрутизацию через опции конфигов и iptables.
У себя на сервере вы используете опцию push "redirect-gateway def1 bypass-dhcp", а это значит, что весь трафик в интернет без исключения заворачивается в openvpn к вам на сервер (вы именно этого хотели?), поэтому настройка маршрутизации на сервере необходима.

Answer 2

[cskamsk]

Порт 5000 открыт наружу изначально. Вот все открытые порты

netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1343/sshd       
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      1290/exim4      
tcp6       0      0 :::139                  :::*                    LISTEN      971/smbd        
tcp6       0      0 :::21                   :::*                    LISTEN      8657/proftpd: (acce
tcp6       0      0 :::22                   :::*                    LISTEN      1343/sshd       
tcp6       0      0 ::1:25                  :::*                    LISTEN      1290/exim4      
tcp6       0      0 :::445                  :::*                    LISTEN      971/smbd        
udp        0      0 10.8.0.1:123            0.0.0.0:*                           1061/ntpd       
udp        0      0 a.b.c.d:123      0.0.0.0:*                           1061/ntpd       
udp        0      0 127.0.0.1:123           0.0.0.0:*                           1061/ntpd       
udp        0      0 0.0.0.0:123             0.0.0.0:*                           1061/ntpd       
udp        0      0 a.b.c.d:5000     0.0.0.0:*                           1322/openvpn    
udp        0      0 a.b.e.f:137     0.0.0.0:*                           955/nmbd        
udp        0      0 a.b.c.d:137      0.0.0.0:*                           955/nmbd        
udp        0      0 0.0.0.0:137             0.0.0.0:*                           955/nmbd        
udp        0      0 a.b.e.f:138     0.0.0.0:*                           955/nmbd        
udp        0      0 a.b.c.d:138      0.0.0.0:*                           955/nmbd        
udp        0      0 0.0.0.0:138             0.0.0.0:*                           955/nmbd

По странному стечению обстоятельств файл openvpn.log вообще не пишется. Его в этой папке нет. Ключи переписал. Опцию не включал - все клиенты ходят по собственным PKCS12.
После всех проделок клиенты получают адреса и ходят в сеть через сервер, но друг друга они не видят. Есть ли мануал какой-нибудь по маршрутиризации для openvpn, c *nix почти не знаком?

Comments

[Panfilov]

1)для логирования в конфиг на сервере необходимо вставить опцию
log /var/log/openvpn.log
или
log-append /var/log/openvpn.log

2)соединения клиентов сервером есть - хорошо. Осталась маршрутизация

В Вашем случае необходимо, чтобы в конфиге сервера была опция client-to-client (это есть уже).

Далее нужно разрешающее правило в iptables в таблице FORWARD на сквозную передачу пакетов через интерфейс tun в сети 10.8.0.0
что-то типа iptables -A FORWARD -s 10.8.0.0/24 -i tun0 -j ACCEPT
(после перезагрузки сервера правила сбрасываются в iptables, если это отдельно не настроено).

И третье - опция iroute 10.8.0.0 255.255.255.0 в файлах в ccd/ вам не нужна - эта опция нужна для маршрутизации подсети, находящейся за клиентом, если такая имеется, у вас этого нет, насколько я вижу. Таким образом получается, что ccd/ папка вам вообще без надобности.

3) часть информации можно почерпнуть отсюда
habrahabr.ru/sandbox/23046
lithium.opennet.ru/articles/openvpn/openvpn-howto.html

[Panfilov]

скорее всего вам даже iptables правило не нужно (нет других подсетей), но и не помешает ничем
все дело в опции iroute насколько я сейчас вижу

[cskamsk]

Таблица настроилась, пинг между клиентами на сети 10.8.0.0/24 есть. Общего доступа к файлам по-прежнему нет. Сейчас пытаюсь соединить OSX с Андроидом, но все попытки через ES Explorer получить доступ к mac тщетны.
Из лога сервера: [клиент выходит в сеть через GSM-модем]
client/213.87.128.166:30822 MULTI: bad source address from client [192.168.66.2], packet dropped

[Panfilov]

приведите вывод c сервера команд
route и iptables -L

[Panfilov]

а адреса вида 192.168.66.2 - откуда такие?

[cskamsk]

Маршруты
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.8.0.2 * 255.255.255.255 UH 0 0 0 tun0
10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0
xxx.226.224.0 * 255.255.240.0 U 0 0 0 eth0
default xxx.226.224.1 0.0.0.0 UG 0 0 0 eth0

Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 10.8.0.0/24 anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT all -- 10.8.0.0/24 192.168.1.0/24
ACCEPT all -- 192.168.1.0/24 10.8.0.0/24
ACCEPT all -- 10.8.0.0/24 10.8.0.0/24
ACCEPT all -- 192.168.1.0/24 192.168.1.0/24

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Сеть 192.168/24 находится дома за NAT. 10.8/24 - на сервере

[cskamsk]

Адрес 192.168.66.2 внутренний для GSM сети

[Panfilov]

на сервере в ccd/ папке для этого клиента необходимо указать опцию iroute 192.168.66.0 255.255.255.0

эта опция скажет серверу, что у этого клиента за ним есть сеть 66.0/24 и пакеты в эту сеть необходимо передать именно этому клиенту (а далее он сам разберется со своим NAT)
Сейчас сервер дропает пакеты 66.0/24, так как ему ничего не известно о сети 192.168.66.0

возможно потребуются 2 правила iptables
Chain FORWARD (policy ACCEPT)
ACCEPT all -- 10.8.0.0/24 192.168.66.0/24 (тут правда уже есть более общее правило ACCEPT all -- 10.8.0.0/24 anywhere)
и обратное
ACCEPT all -- 192.168.66.0/24 10.8.0.0/24

[Panfilov]

в выводе route должна появится строка вида
192.168.66.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0

[cskamsk]

Практически заработало! Заново поднял сервер, обновил маршруты и настройки для каждого клиента в ccd. ES Explorer теперь видит компьютеры в сети 10.8/24. Остались только 3 нерешенных вопроса.

Стандартными средствами внутренности android клиент windows видеть не желает. Только пингует да и дает просматривать себя на уровне прав текущего пользователя. Как быть?

Команда push "redirect-gateway def1 bypass-dhcp" отправляет весь внешний траффик клиентов наружу? Как разграничить тунеллирование внутри сети и в интернет?

Как перейти от ip в обозначениях клиентов к рабочим группам и названиям компьютеров, как в сетях windows?

[cskamsk]

Тут еще вот какая загвоздка. Тестовый файл между клиентами идет со скоростью 10Кб/сек. Хотя скорость канала более 20Мбит. Вряд ли такую низкую скорость дает шифрование.
В логе [клиенты идут как ams001...ams999]

ams001/xxx.yyy.35.55:57558 MULTI: bad source address from client [имеется ввиду ams005] [fe80::95dd:67bf:45bd:30a2]

IPv6 на стороне клиента поддерживает маршрутиризатор на 192.168.1.1, отключить поддержку v6 не представляется возможным.
Конфиг ccd для ams005 выглядит как
10.8.0.21 10.8.0.22
push "route 10.8.0.0 255.255.255.0"

[Panfilov]

>>>Команда push "redirect-gateway def1 bypass-dhcp" отправляет весь внешний траффик клиентов наружу? Как разграничить тунеллирование внутри сети и в интернет?
я думаю, эта опция вам не нужна. С ней весь трафик идет в openvpn на сервер,
без нее сеть 10.8.0.0/24 пойдет на сервер, остальной трафик напрямую.
Попробуйте без нее.

>>>Как перейти от ip в обозначениях клиентов к рабочим группам и названиям компьютеров, как в сетях windows?

Сети Windows работают в одной подсети и на уровне L2.
Это нужно было изначально поднимать L2-туннель в openvpn (опция dev tap)
Сейчас у вас L3-туннель (опция dev tun).
Там не будет роутинга и маршрутизации подсетей, а устройства будут общаться на уровне mac-адресов. Непонятно только, что делать с вашей nat-сетью. Здесь я вам ничем помочь не смогу, так как такое никогда не настраивал за ненадобностью.

в файле hosts в windows можно назначить имена для ip-адресов (что-то типа локального dns), но универсального решения тут нет. Разрешением имен занимается DNS, в сетях windows есть NetBios, ну и все.

>>>Стандартными средствами внутренности android клиент windows видеть не желает. Только пингует да и дает просматривать себя на уровне прав текущего пользователя. Как быть?

от openvpn и маршрутизация (а также типа сетей L2 - L3) это не зависит.
Это уже надо смотреть какие привилегии сам андроид может давать при сетевом входе. Это политики аутентификации устройства и возможности программ типа ES Explorer и т.п.

[Panfilov]

в server.conf вставить строки
route 192.168.66.0 255.255.255.0
push "route 192.168.66.0 255.255.255.0"
в ccd/ams005 строка push "route 10.8.0.0 255.255.255.0" вроде как лишняя

про ipv6 и сеть 192.168.1.1 пока не пойму, каким образом они влияют, так не вижу полной топологии сети. Видимо какие-то перекрещивающиеся маршруты - вот и скорость низкая, а ipv6 при этом дропается в openvpn.