Openvpn UBUNTU srv(за NAT) + openvpn-client Mikrotik

[beneshe]

Собирал по этому мануалу:

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

http://habrahabr.ru/post/227767/

конф сервака получился таким.

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

port 1194
proto tcp
dev tun


dh /etc/openvpn/dh.pem
ca /etc/openvpn/ca.crt
cert /etc/openvpn/vpn-srv.crt
key /etc/openvpn/vpn-srv.key

server 10.15.0.0 255.255.255.0
#client-config-dir /etc/openvpn/ccd
client-to-client
keepalive 10 120
tun-mtu 1500
mssfix 1450
cipher AES-256-CBC   # AES
auth sha1

push "dhcp-option DNS 192.168.27.1"
push "dhcp-option DNS 192.168.27.5"

route 10.15.0.0 255.255.255.0
push "route 192.168.27.0 255.255.255.0"




user nobody
group nogroup
persist-key
persist-tun

status /var/log/openvpn-status.log
log  /var/log/openvpn.log
verb 3
mute 10

"мАкротик" плюется
Status: established
Status: terminating... - peer disconnected

да.. телнетом цепляюсь на сервак - порт доступен.

подмогните столкнуть с мертвой точки

[fisher74]

что в /var/log/openvpn.log?
На микротике сертификаты правильные? Что у него в логе?
Можете на полноценном компе клиента попробовать запустить?

[beneshe]

Это огрызок лога с сервака.

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

at Feb  7 16:47:51 2015 hvoiki/37.53.245.198:50116 Authenticate/Decrypt packet error: cipher final failed
Sat Feb  7 16:47:51 2015 hvoiki/37.53.245.198:50116 Fatal decryption error (process_incoming_link), restarting
Sat Feb  7 16:47:51 2015 hvoiki/37.53.245.198:50116 SIGUSR1[soft,decryption-error] received, client-instance restarting
Sat Feb  7 16:47:56 2015 TCP connection established with [AF_INET]37.53.245.198:50117
Sat Feb  7 16:47:57 2015 37.53.245.198:50117 TLS: Initial packet from [AF_INET]37.53.245.198:50117, sid=56995e03 4163e918
Sat Feb  7 16:48:01 2015 37.53.245.198:50117 VERIFY OK: depth=1, CN=HO
Sat Feb  7 16:48:01 2015 37.53.245.198:50117 VERIFY OK: depth=0, CN=hvoiki
Sat Feb  7 16:48:02 2015 37.53.245.198:50117 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1559', remote='link-mtu 1543'
Sat Feb  7 16:48:02 2015 37.53.245.198:50117 WARNING: 'cipher' is used inconsistently, local='cipher AES-256-CBC', remote='cipher BF-CBC'
Sat Feb  7 16:48:02 2015 37.53.245.198:50117 WARNING: 'keysize' is used inconsistently, local='keysize 256', remote='keysize 128'
Sat Feb  7 16:48:02 2015 37.53.245.198:50117 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Sat Feb  7 16:48:02 2015 37.53.245.198:50117 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Feb  7 16:48:02 2015 37.53.245.198:50117 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Sat Feb  7 16:48:02 2015 37.53.245.198:50117 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sat Feb  7 16:48:02 2015 37.53.245.198:50117 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Sat Feb  7 16:48:02 2015 37.53.245.198:50117 [hvoiki] Peer Connection Initiated with [AF_INET]37.53.245.198:50117
Sat Feb  7 16:48:02 2015 hvoiki/37.53.245.198:50117 MULTI_sva: pool returned IPv4=10.15.0.2, IPv6=(Not enabled)
Sat Feb  7 16:48:02 2015 hvoiki/37.53.245.198:50117 MULTI: Learn: 10.15.0.2 -> hvoiki/37.53.245.198:50117
Sat Feb  7 16:48:02 2015 hvoiki/37.53.245.198:50117 MULTI: primary virtual IP for hvoiki/37.53.245.198:50117: 10.15.0.2
Sat Feb  7 16:48:04 2015 hvoiki/37.53.245.198:50117 PUSH: Received control message: 'PUSH_REQUEST'
Sat Feb  7 16:48:04 2015 hvoiki/37.53.245.198:50117 send_push_reply(): safe_cap=940
Sat Feb  7 16:48:04 2015 hvoiki/37.53.245.198:50117 SENT CONTROL [hvoiki]: 'PUSH_REPLY,dhcp-option DNS 192.168.27.1,dhcp-option DNS 192.168.27.5,route 192.168.27.0 255.255.255.0
,route-gateway 10.15.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.15.0.2 255.255.255.0' (status=1)
Sat Feb  7 16:48:07 2015 Closing TUN/TAP interface
Sat Feb  7 16:48:07 2015 /sbin/ip addr del dev tun0 10.15.0.1/24
RTNETLINK answers: Operation not permitted
Sat Feb  7 16:48:07 2015 Linux ip addr del failed: external program exited with error status: 2
Sat Feb  7 16:48:07 2015 SIGTERM[hard,] received, process exiting

это лог виндового клиента(запускаю из-под админа)

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

Sat Feb 07 18:48:48 2015 Authenticate/Decrypt packet error: cipher final failed
Sat Feb 07 18:48:48 2015 Fatal decryption error (process_incoming_link), restarting
Sat Feb 07 18:48:48 2015 SIGUSR1[soft,decryption-error] received, process restarting
Sat Feb 07 18:48:53 2015 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Sat Feb 07 18:48:53 2015 Attempting to establish TCP connection with [AF_INET]XXX.XXX.XXX.XXX:2222 [nonblock]
Sat Feb 07 18:48:54 2015 TCP connection established with [AF_INET]XXX.XXX.XXX.XXX:2222
Sat Feb 07 18:48:54 2015 TCPv4_CLIENT link local: [undef]
Sat Feb 07 18:48:54 2015 TCPv4_CLIENT link remote: [AF_INET]XXX.XXX.XXX.XXX:2222


""ОШИБКИ""

Sat Feb 07 18:48:56 2015 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1543', remote='link-mtu 1559'
Sat Feb 07 18:48:56 2015 WARNING: 'cipher' is used inconsistently, local='cipher BF-CBC', remote='cipher AES-256-CBC'
Sat Feb 07 18:48:56 2015 WARNING: 'keysize' is used inconsistently, local='keysize 128', remote='keysize 256'

""ОШИБКИ""

Sat Feb 07 18:48:56 2015 [HO] Peer Connection Initiated with [AF_INET]XXX.XXX.XXX.XXX:2222
Sat Feb 07 18:48:59 2015 Preserving previous TUN/TAP instance: Подключение по локальной сети
Sat Feb 07 18:48:59 2015 Initialization Sequence Completed
Sat Feb 07 18:49:09 2015 Connection reset, restarting

Sat Feb 07 18:49:09 2015 SIGUSR1[soft,connection-reset] received, process restarting
Sat Feb 07 18:49:14 2015 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Sat Feb 07 18:49:14 2015 Attempting to establish TCP connection with [AF_INET]XXX.XXX.XXX.XXX:22221 [nonblock]
Sat Feb 07 18:49:15 2015 TCP connection established with [AF_INET]XXX.XXX.XXX.XXX:2222
Sat Feb 07 18:49:15 2015 TCPv4_CLIENT link local: [undef]
Sat Feb 07 18:49:15 2015 TCPv4_CLIENT link remote: [AF_INET]XXX.XXX.XXX.XXX:2222

Sat Feb 07 18:49:18 2015 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1543', remote='link-mtu 1559'
Sat Feb 07 18:49:18 2015 WARNING: 'cipher' is used inconsistently, local='cipher BF-CBC', remote='cipher AES-256-CBC'
Sat Feb 07 18:49:18 2015 WARNING: 'keysize' is used inconsistently, local='keysize 128', remote='keysize 256'
Sat Feb 07 18:49:18 2015 [HO] Peer Connection Initiated with [AF_INET]XXX.XXX.XXX.XXX:2222
Sat Feb 07 18:49:20 2015 Preserving previous TUN/TAP instance: Подключение по локальной сети
Sat Feb 07 18:49:20 2015 Initialization Sequence Completed

виндовый конф(клиент)

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

dev tun
proto tcp
remote XXX.XXX.XXX.XXX 2222
client
#resolv-retry infinite


ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"
cert "C:\\Program Files\\OpenVPN\\config\\hvoiki.crt"
key "C:\\Program Files\\OpenVPN\\config\\hvoiki.key"


#tls-auth "C:\\Program Files\\OpenVPN\\config\\.key" 1
#ns-cert-type server
#remote-cert-tls server
#ifconfig 10.15.0.0 255.255.255.0
persist-key
persist-tun

route-delay 5
route-method exe
ip-win32 netsh


#comp-lzo
#verb 3
#status /var/log/openvpn/openvpn-status.log 1
status-version 3
#log-append /var/log/openvpn/openvpn-client.log

мокротик пишет

initializing
connecting
disconnected (peer disconnected)

[anubis_donetsk]

1. link-mtu - сделать одинаковым
2. cipher - сделать одинаковым
3. keysize - сделать одинаковым

Както так.

[beneshe]

Вынужден с Вами согласиться!

Но есть нюанс, эти ошибки сыпятся от "виндового" клиента.

Ибо ДА есть несоответствия в конфах СЕРВА и КЛИЕНТА.

Макротик настраивал с учетом настроек СЕРВА.

Че еще можно глянуть на Макротике
Пользователь решил продолжить мысль [time]07 Февраль 2015, 23:30:46[/time]:Нашел загвоздку.

Ошибка в настройках макротика, не указал сертификат который необходимо использовать.



Interfaces --- интерфейс "openvpn" Certificate="номер вашего сертификата", как-то так.




Подмогните пожалуйста настроить маршрутизацию.

                                                                                         
сеть 192.168.28.0/24 - макротик(белый IP) <--------> (белый IP) GW|freebsd| сеть 192.168.27.0/24(openvpn-srv)
                                                                         

Из "28" подсети через впн ходят пинги до сети "27" тут порядок(ну я так надеюсь)
мне надо прописать маршруты из "27" в "28" это надо сделать на  сервере "Ubuntu openvpn-srv" и шлюзе "GW freebsd"

[fisher74]

добавляйте клиента в ccd и применяйте команду iroute. Как именно и сделать и многое другое в местной библиотеке
Только учитывая Вашу схему, могут проявиться проблемы из-за того, что у  27-ой сети дефолтный шлюз не сервер OpenVPN. Если это так, то ещё нужно будет на фряхе маршрут доавить.
И это... скорее всего клиентская сторона пингует только сервер OpenVPN, а остальных нет... либо настроен маскарад.

[beneshe]

добавляйте клиента в ccd и применяйте команду iroute.

Сделал.

но смущает, что в таком случае строчки в конфе сервака которые дублируют строки в ссd

serv.conf

route 10.15.0.0 255.255.255.0
push "route 192.168.27.0 255.255.255.0"
push "route 192.168.28.0 255.255.255.0"

/etc/openvpn/ccd/client

iroute 192.168.28.0 255.255.255.0
push "route 192.168.27.0 255.255.255.0"

Насчет того, что видит только шлюз за впн, я немногим раньше делал "НАТ" так, что видит всю сеть.
на сервере "Openvpn" маршрут прокинул такой командой:

route add -net 192.168.28.0/24 gw 10.15.0.2 via tun0
пинги в сеть пошли.

теперь как-то надо объяснить машине с "фрей" что пакеты в "28" сеть надо отсылать через сервер openvpn
пробую делать так:

route add -net 192.168.28.0/24 192.168.27.29(сервер openvpn)

пишет:

route: bad address: 192.168.28.0/24

подскажите, что не так.


В догонку еще вопрос.
В "27" сети живет ДНС сервер(виндовый контроллер домена).
Как и что нужно накрутить чтобы из "28" по имени можно было попасть на сервер терминалов.

[fisher74]

но смущает, что в таком случае строчки в конфе сервака которые дублируют строки в ссd

Не дублируйте.
Всё просто: общие настройки в основной конфиг, персональные - в ccd-конфиг

теперь как-то надо объяснить машине с "фрей" что пакеты в "28" сеть надо отсылать через сервер openvpn
пробую делать так:

route add -net 192.168.28.0/24 192.168.27.29(сервер openvpn)

10 секунд гугления и ответ на этот вопрос перед глазами

route add -net 192.168.28.0/24 192.168.27.29

или если хотите с -net, то

route add -net 192.168.28.0/24 -netmask 255.255.255.0 192.168.27.29

чем мой гугл отличается от Вашего?

[beneshe]

чем мой гугл отличается от Вашего?

Ваш проплачен, шутка

А на самом деле все гениальное просто. Я точно так и делал, но в связи с тем, что я до этого пытался настроить IPSEC на "фре" для связки с "мокротиком" но не удачно и там в настройках фигурировала "28" подсеть. закоментил строки в rc.conf
и маршрут вроде как прописался. но в "28" пакеты не идут((( видимо идут в лес не той дорогой.

[fisher74]

rc.conf это хорошо, а что в текущей таблице маршрутизации? Перепроверьте всех участников.

[beneshe]

Это кусок фри

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

Internet:
Destination        Gateway            Flags    Refs      Use  Netif Expire
default            XXX.XXX.XXX.XXX     UGS         0     2052    em0
127.0.0.1          127.0.0.1          UH          0        0    lo0
192.168.25.0/24    gif0               US          0       46   gif0
192.168.25.254     192.168.27.56      UH          0        0   gif0
192.168.27.0/24    link#3             UC          0        0   fxp0
192.168.27.1       00:1e:c9:f8:e9:f5  UHLW        1      691   fxp0   1196
192.168.27.3       00:18:f3:c5:0f:de  UHLW        1        0   fxp0   1197
192.168.27.5       00:0c:29:7f:46:f1  UHLW        1        9   fxp0   1196
192.168.27.9       00:0c:29:5a:32:00  UHLW        1       39   fxp0   1049
192.168.27.29      00:0c:29:76:cb:87  UHLW        2      261   fxp0   1185
192.168.27.69      00:0c:29:4f:f2:7d  UHLW        1        0   fxp0   1166
192.168.27.90      6c:f0:49:5c:7b:d0  UHLW        1      256   fxp0   1191
192.168.28.0/24    192.168.27.29      UGS         0        0   fxp0
XXX.XXX.XXX.XXX/30  link#1             UC          0        0    em0
XXX.XXXX.XXX.XXX     64:87:88:5b:8a:5a  UHLW        2        0    em0    997

это на openvpn серве.

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

Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.27.56   0.0.0.0         UG        0 0          0 eth0
10.15.0.0       10.15.0.2       255.255.255.0   UG        0 0          0 tun0
10.15.0.2       0.0.0.0         255.255.255.255 UH        0 0          0 tun0
192.168.2.0     0.0.0.0         255.255.255.0   U         0 0          0 eth1
192.168.27.0    0.0.0.0         255.255.255.0   U         0 0          0 eth0
192.168.28.0    10.15.0.2       255.255.255.0   UG        0 0          0 tun0

Iptables openvpn

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

root@ubuntu:/home/ing# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

[fisher74]

на вид всё прилично. А с микротиковской стороны? Микротик основной шлюз?
Трассируйте и поймёте где затык

Сейчас проскроллил хаброгайд... Вы поди и маскарад включили, как там описано

[beneshe]

Маскарад, да включил так же только с другого гайда. Но у меня еще есть правило перед "нат" в "27" из "28" цепочка "srcnat".

Насчет трасировки:

    с сервера "openvpn" пакеты летят аж душа радуется.
    а вот на фре затыкаются на первом же хопе.

[fisher74]

можь на фряхе файер жадничает? С неё пинги проходят?
Предалагаю для временного исключения фряхи добавить статический маршрут на тестируемой машине. Если всё ОК, то уже решать проблему с фрёй, если нет - то копать дальше в туннеле.

[beneshe]

С утра приехал на офис и тут же затык.

На макротике через туннель видит "27" сеть, а клиенты за макротиком нет. нехватка маршрута или правила какого подскажите плз, а то уже сапоги начищают будут бить скоро.

А про непроходимость пингов я говорил как раз про те что с фряхи не идут.
Только решу вопрос со входом на "gw" главного офиса, сразу кину список правил "фри".