LINUX.ORG.RU
Форум — Admin  

OpenVPN Server Bridge Mode

 ,


0

1

Здравствуйте!

Имеется локальная сеть с десятками vlan-ов, OpenVPN сервер на Debian и маршрутизатор Cisco 2921 на границе сети.

Сервер OpenVPN натится циской и клиенты подключаются к нему из интернет.

OpenVPN сервер работает в режиме bridge, находится в подсети 10.10.10.0/24 и имеет адрес 10.10.10.1. Клиенты получают адреса из диапазона 10.10.10.10 - 10.10.10.250. Необходимо чтобы клиенты видели сети 172.17.17.0/24, 172.17.18.0/24 и т.д. и маршрутизация и весь трафик проходил на Cisco 2921.

С текущей конфигурацией трафик у меня на Cisco уходит, но назад не возвращается. Gateway на Cisco 172.17.17.254, 172.17.18.254 и т.д.

Помогите, пожалуйста.

Конфиг сервера 

mode server
port 443
proto tcp
dev tap0
user openvpn
group openvpn
dh /etc/openvpn/keys/dh.pem
ca /etc/openvpn/keys/CA.crt
cert /etc/openvpn/keys/VFA-VPNO-0001-V.cer
key /etc/openvpn/keys/VFA-VPNO-0001-V.key
crl-verify /etc/openvpn/keys/certcrl.crl
tls-auth /etc/openvpn/keys/ta.key 0
script-security 2
cipher AES-256-CBC
mute 10
persist-key
persist-tun
keepalive 10 900
client-config-dir /etc/openvpn/ccd

topology subnet

server-bridge 10.10.10.1 255.255.255.0 10.10.10.10 10.10.10.250

route 172.17.23.0 255.255.255.0 10.10.10.1
route 172.17.17.0 255.255.255.0 10.10.10.1
route 172.17.19.0 255.255.255.0 10.10.10.1

push "route 172.17.17.0 255.255.255.0 10.10.10.1"
push "route 172.17.19.0 255.255.255.0 10.10.10.1"
push "route 172.17.23.0 255.255.255.0 10.10.10.1"


route-method exe
client-to-client

status /var/log/openvpn/openvpn-status.log
log-append /var/log/openvpn/openvpn-server.log
verb 4

tun-mtu 1200
mssfix 1450

plugin /usr/lib/openvpn/openvpn-auth-ldap.so /etc/openvpn/ldap.conf
username-as-common-name

Client CCD 

ifconfig-push 10.10.10.15 255.255.255.0

sudo ip ro 

default via 10.10.10.254 dev br0
10.10.10.0/24 dev br0  proto kernel  scope link  src 10.10.10.1
172.17.17.0/24 via 10.10.10.1 dev br0
172.17.19.0/24 via 10.10.10.1 dev br0
172.17.23.0/24 via 10.10.10.1 dev br0

sudo iptables-save 

# Generated by iptables-save v1.4.21 on Mon Jul  4 12:36:55 2016
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [5213:632521]
-A INPUT -i tap0 -j ACCEPT
-A INPUT -i br0 -j ACCEPT
-A FORWARD -i br0 -j ACCEPT
COMMIT
# Completed on Mon Jul  4 12:36:55 2016
# Generated by iptables-save v1.4.21 on Mon Jul  4 12:36:55 2016
*nat
:PREROUTING ACCEPT [228:15962]
:INPUT ACCEPT [15:816]
:OUTPUT ACCEPT [92:5759]
:POSTROUTING ACCEPT [305:20905]
COMMIT
# Completed on Mon Jul  4 12:36:55 2016

sudo ifconfig 

br0       Link encap:Ethernet  HWaddr 00:0c:29:44:9a:1f
          inet addr:10.10.10.1  Bcast:10.10.10.255  Mask:255.255.255.0
          inet6 addr: fe80::20c:29ff:fe44:9a1f/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:774 errors:0 dropped:0 overruns:0 frame:0
          TX packets:522 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:88687 (86.6 KiB)  TX bytes:64779 (63.2 KiB)

eth0      Link encap:Ethernet  HWaddr 00:0c:29:44:9a:1f
          inet6 addr: fe80::20c:29ff:fe44:9a1f/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:7984 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7738 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1069938 (1.0 MiB)  TX bytes:1012255 (988.5 KiB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

tap0      Link encap:Ethernet  HWaddr 66:e5:8d:c9:2f:a4
          inet6 addr: fe80::64e5:8dff:fec9:2fa4/64 Scope:Link
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:172 errors:0 dropped:4 overruns:0 frame:0
          TX packets:154 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:19118 (18.6 KiB)  TX bytes:11838 (11.5 KiB)

← Ротация логов apache
Как быстро сохранить бэкап одновременно на два разных диска локальной машины? →

ЕМНИП «10.10.10.1» в пушах и роутах не нужно. Сервер и клиент сами подставят нужный адрес.

На стороне сервера там будет IP-адрес сервера, а на стороне клиента там будет IP-адрес клиента.

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

Убрал 10.10.10.1 из пушей и роутов, ничего не изменилось. Все равно с клиента не вижу локальную сеть, хотя до циски пакеты долетают. То есть циска видит IP-адрес клиента и пакеты от него на нее приходят, а обратно до клиента я так понимаю не доходят.

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

А у тебя все вот эти сети знают про openvpn? Маскарадинг попробуй для начала сделать, если попрёт трафик от клиента, то на стороне сервера и сети за ним маршрутов не хватает.

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

А у тебя все вот эти сети знают про openvpn? Не совсем понял эту фразу, что это значит? У меня все сети нарезаны на маршрутизаторе. Маскардинг я до этого пробовал - он работает. Сейчас понадобилось чтобы на циске были видны реальные адреса клиентов, а не сервера OpenVPN. PS: После того как убрал 10.10.10.1 из роутов и пушей на сервере таблица маршрутов стала следующая: 

sudo ip ro
default via 10.10.10.254 dev br0
10.10.10.0/24 dev br0  proto kernel  scope link  src 10.10.10.1

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

А push «route 172.17.17.0 255.255.255.0 10.10.10.1»
10.10.10.1 это не разу же не она? Перечитал пост, ну точно же не она.

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 2)

Если я правильно понял, то openvpn - это отдельная машина в сети со своими замутами, 10.10.10.0/24 - это сеть за IP_openvpn, но кошка про нее ничего не знает.

По идее тебе надо на кошке прописать маршрут до 10.10.10.0/24 через IP_openvpn, тогда трафик от твоих сетей дойдет до клиентов openvpn.

Т.е. если у машины с openvpn адрес в сети 192.168.1.100, то маршрут для 10.10.10.0/24 надо прописывать через него, а на самой машине форвардинг разрешить.

Я такую конфигурацию не пробовал строить, у меня openvpn прямо на роутере работает.

Radjah ★★★★★
()
Последнее исправление: Radjah (всего исправлений: 1)
Ответ на: комментарий от Radjah

Вообще у ТС что-то странное твориться или он не договаривает.

10.10.10.0/24 - это сеть за IP_openvpn

Он написал что бридж. и «Конечно в курсе, на сервере дефолтный gateway и есть Cisco.»

route 172.17.17.0 255.255.255.0 10.10.10.1

Явно не на киску отправляются
При этом он пишет

хотя до циски пакеты долетают

По Станиславскому «Не верю» с какого фига они вообще туда отправиться должны?

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

Тогда в route должен быть адрес цыски по идее.

По уму еще бы лог запуска сервера и лог подключения клиента глянуть.

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

Я так понял, что сеть 10.10.10.0/24 - это НЕ сеть за IP_openvpn, а собственно сама виртуальная сеть openvpn, совмещенная посредством моста с реальной сетью. Далее у ТС на серваке openvpn создается мост между виртуальным интерфейсом openvpn и физ. интерфейсом, находящимся в одной подсети с cisco (сеть 10.10.10.0/24), где адрес cisco 10.10.10.254 .

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

Короче, пока, при текущей инфе, я бы хотел таблицу маршрутизации на cisco посмотреть, ну и до кучи адреса всех ее интерфейсов + маски и т.д..

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

sh ip route 

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        10.10.10.0/24 is directly connected, GigabitEthernet0/2.1010
L        10.10.10.254/32 is directly connected, GigabitEthernet0/2.1010
      172.17.0.0/16 is variably subnetted, 35 subnets, 2 masks
C        172.17.11.0/24 is directly connected, GigabitEthernet0/2.11
L        172.17.11.254/32 is directly connected, GigabitEthernet0/2.11
C        172.17.12.0/24 is directly connected, GigabitEthernet0/2.12
L        172.17.12.254/32 is directly connected, GigabitEthernet0/2.12
C        172.17.13.0/24 is directly connected, GigabitEthernet0/2.13
L        172.17.13.254/32 is directly connected, GigabitEthernet0/2.13
C        172.17.14.0/24 is directly connected, GigabitEthernet0/2.14
L        172.17.14.254/32 is directly connected, GigabitEthernet0/2.14
C        172.17.15.0/24 is directly connected, GigabitEthernet0/2.15
L        172.17.15.101/32 is directly connected, GigabitEthernet0/2.15
L        172.17.15.254/32 is directly connected, GigabitEthernet0/2.15
C        172.17.16.0/24 is directly connected, GigabitEthernet0/2.16
L        172.17.16.254/32 is directly connected, GigabitEthernet0/2.16
C        172.17.17.0/24 is directly connected, GigabitEthernet0/2.17
L        172.17.17.254/32 is directly connected, GigabitEthernet0/2.17
C        172.17.18.0/24 is directly connected, GigabitEthernet0/2.18
L        172.17.18.254/32 is directly connected, GigabitEthernet0/2.18
C        172.17.19.0/24 is directly connected, GigabitEthernet0/2.19
L        172.17.19.254/32 is directly connected, GigabitEthernet0/2.19
C        172.17.20.0/24 is directly connected, GigabitEthernet0/2.20
L        172.17.20.254/32 is directly connected, GigabitEthernet0/2.20
C        172.17.21.0/24 is directly connected, GigabitEthernet0/2.21
L        172.17.21.254/32 is directly connected, GigabitEthernet0/2.21
C        172.17.22.0/24 is directly connected, GigabitEthernet0/2.22
L        172.17.22.254/32 is directly connected, GigabitEthernet0/2.22
C        172.17.23.0/24 is directly connected, GigabitEthernet0/2.23
L        172.17.23.254/32 is directly connected, GigabitEthernet0/2.23
C        172.17.24.0/24 is directly connected, GigabitEthernet0/2.24
L        172.17.24.254/32 is directly connected, GigabitEthernet0/2.24
C        172.17.25.0/24 is directly connected, GigabitEthernet0/2.25
L        172.17.25.254/32 is directly connected, GigabitEthernet0/2.25
C        172.17.26.0/24 is directly connected, GigabitEthernet0/2.26
L        172.17.26.254/32 is directly connected, GigabitEthernet0/2.26
C        172.17.27.0/24 is directly connected, GigabitEthernet0/2.27
L        172.17.27.254/32 is directly connected, GigabitEthernet0/2.27

sh run Кое-что не относящееся к теме убрал.

interface GigabitEthernet0/0
 description ### Miran-BGP ###
 ip address 91.142.80.106 255.255.255.252
 ip access-group 145 in
 ip access-group 145 out
 ip nat outside
 ip virtual-reassembly in
 duplex auto
 speed auto
!
interface GigabitEthernet0/1
 description ### Komfortel ###
 ip address 37.139.40.253 255.255.255.0
 ip nat outside
 ip virtual-reassembly in
 duplex auto
 speed auto
!
interface GigabitEthernet0/2
 no ip address
 duplex auto
 speed auto
!
interface GigabitEthernet0/2.11
 description VFA-HSUP-HARD
 encapsulation dot1Q 11
 ip address 172.17.11.254 255.255.255.0
!
interface GigabitEthernet0/2.12
 description VFA-HFRM-HARD
 encapsulation dot1Q 12
 ip address 172.17.12.254 255.255.255.0
!
interface GigabitEthernet0/2.13
 description VFA-HSUP-MGMT
 encapsulation dot1Q 13
 ip address 172.17.13.254 255.255.255.0
!
interface GigabitEthernet0/2.14
 description VFA-HFRM-MGMT
 encapsulation dot1Q 14
 ip address 172.17.14.254 255.255.255.0
!
interface GigabitEthernet0/2.15
 description VFA-TCOM-MGMT
 encapsulation dot1Q 15
 ip address 172.17.15.254 255.255.255.0 secondary
 ip address 172.17.15.101 255.255.255.0
!
interface GigabitEthernet0/2.16
 description VFA-REMT
 encapsulation dot1Q 16
 ip address 172.17.16.254 255.255.255.0
 ip virtual-reassembly in
!
interface GigabitEthernet0/2.17
 description VFA-CORE
 encapsulation dot1Q 17
 ip address 172.17.17.254 255.255.255.0
!
interface GigabitEthernet0/2.18
 description VFA-LAND
 encapsulation dot1Q 18
 ip address 172.17.18.254 255.255.255.0
!
interface GigabitEthernet0/2.19
 description VFA-XRAY
 encapsulation dot1Q 19
 ip address 172.17.19.254 255.255.255.0
!
interface GigabitEthernet0/2.20
 description VFA-BACK
 encapsulation dot1Q 20
 ip address 172.17.20.254 255.255.255.0
!
interface GigabitEthernet0/2.21
 description VFA-SCAN
 encapsulation dot1Q 21
 ip address 172.17.21.254 255.255.255.0
!
interface GigabitEthernet0/2.22
 description VFA-UPDT
 encapsulation dot1Q 22
 ip address 172.17.22.254 255.255.255.0
!
interface GigabitEthernet0/2.23
 description VFA-SRVC
 encapsulation dot1Q 23
 ip address 172.17.23.254 255.255.255.0
!
interface GigabitEthernet0/2.24
 description VFA-WAPP
 encapsulation dot1Q 24
 ip address 172.17.24.254 255.255.255.0
!
interface GigabitEthernet0/2.25
 description VFA-DATA
 encapsulation dot1Q 25
 ip address 172.17.25.254 255.255.255.0
!
interface GigabitEthernet0/2.26
 description VFA-TEST
 encapsulation dot1Q 26
 ip address 172.17.26.254 255.255.255.0
!
interface GigabitEthernet0/2.27
 description VFA-IMAG
 encapsulation dot1Q 27
 ip address 172.17.27.254 255.255.255.0
!
interface GigabitEthernet0/2.1010
 description VFA-REMT
 encapsulation dot1Q 1010
 ip address 10.10.10.254 255.255.255.0
 ip access-group VFA-VPNO-0001-V-out out
 ip nat inside
 ip virtual-reassembly in
!
!

!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
!
ip nat translation timeout 3600
ip nat translation tcp-timeout 3600
ip nat translation udp-timeout 240
ip nat translation finrst-timeout 30
ip nat translation dns-timeout 45
ip nat inside source static tcp 10.10.10.1 443 37.139.40.253 443 extendable
enterdv
() автор топика
Ответ на: комментарий от Radjah

Лог клиента 

Tue Jul 05 10:40:02 2016 OpenVPN 2.3.11 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on May 10 2016
Tue Jul 05 10:40:02 2016 Windows version 6.2 (Windows 8 or greater) 64bit
Tue Jul 05 10:40:02 2016 library versions: OpenSSL 1.0.1t  3 May 2016, LZO 2.09
Enter Management Password:
Tue Jul 05 10:40:02 2016 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25341
Tue Jul 05 10:40:02 2016 Need hold release from management interface, waiting...
Tue Jul 05 10:40:03 2016 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25341
Tue Jul 05 10:40:03 2016 MANAGEMENT: CMD 'state on'
Tue Jul 05 10:40:03 2016 MANAGEMENT: CMD 'log all on'
Tue Jul 05 10:40:03 2016 MANAGEMENT: CMD 'hold off'
Tue Jul 05 10:40:03 2016 MANAGEMENT: CMD 'hold release'
Tue Jul 05 10:40:07 2016 MANAGEMENT: CMD 'username "Auth" "dkrinitsyn"'
Tue Jul 05 10:40:07 2016 MANAGEMENT: CMD 'password [...]'
Tue Jul 05 10:40:07 2016 WARNING: No server certificate verification method has been enabled.  See http://openvpn.net/howto.html#mitm for more info.
Tue Jul 05 10:40:07 2016 Control Channel Authentication: using 'F:/_VPN/VFA-ovpn/ta.key' as a OpenVPN static key file
Tue Jul 05 10:40:07 2016 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jul 05 10:40:07 2016 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jul 05 10:40:07 2016 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1200)
Tue Jul 05 10:40:07 2016 Socket Buffers: R=[65536->65536] S=[65536->65536]
Tue Jul 05 10:40:07 2016 Attempting to establish TCP connection with [AF_INET]37.139.40.253:443 [nonblock]
Tue Jul 05 10:40:07 2016 MANAGEMENT: >STATE:1467704407,TCP_CONNECT,,,
Tue Jul 05 10:40:08 2016 TCP connection established with [AF_INET]37.139.40.253:443
Tue Jul 05 10:40:08 2016 TCPv4_CLIENT link local: [undef]
Tue Jul 05 10:40:08 2016 TCPv4_CLIENT link remote: [AF_INET]37.139.40.253:443
Tue Jul 05 10:40:08 2016 MANAGEMENT: >STATE:1467704408,WAIT,,,
Tue Jul 05 10:40:08 2016 MANAGEMENT: >STATE:1467704408,AUTH,,,
Tue Jul 05 10:40:08 2016 TLS: Initial packet from [AF_INET]37.139.40.253:443, sid=01c1ba06 e3d387bb
Tue Jul 05 10:40:08 2016 VERIFY OK: depth=1, DC=LOCAL, DC=VIRTUALFORT, CN=VIRTUALFORT-VFA-DCOM-0001-V-CA
Tue Jul 05 10:40:08 2016 VERIFY OK: depth=0, CN=VFA-VPNO-0001-V
Tue Jul 05 10:40:08 2016 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Tue Jul 05 10:40:08 2016 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jul 05 10:40:08 2016 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Tue Jul 05 10:40:08 2016 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jul 05 10:40:08 2016 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Tue Jul 05 10:40:08 2016 [VFA-VPNO-0001-V] Peer Connection Initiated with [AF_INET]37.139.40.253:443
Tue Jul 05 10:40:09 2016 MANAGEMENT: >STATE:1467704409,GET_CONFIG,,,
Tue Jul 05 10:40:10 2016 SENT CONTROL [VFA-VPNO-0001-V]: 'PUSH_REQUEST' (status=1)
Tue Jul 05 10:40:10 2016 PUSH: Received control message: 'PUSH_REPLY,route 172.17.17.0 255.255.255.0,route 172.17.18.0 255.255.255.0,route-gateway 10.10.10.1,ping 10,ping-restart 900,ifconfig 10.10.10.15 255.255.255.0'
Tue Jul 05 10:40:10 2016 OPTIONS IMPORT: timers and/or timeouts modified
Tue Jul 05 10:40:10 2016 OPTIONS IMPORT: --ifconfig/up options modified
Tue Jul 05 10:40:10 2016 OPTIONS IMPORT: route options modified
Tue Jul 05 10:40:10 2016 OPTIONS IMPORT: route-related options modified
Tue Jul 05 10:40:10 2016 ROUTE_GATEWAY 192.168.192.252/255.255.255.0 I=5 HWADDR=10:02:b5:e4:b7:90
Tue Jul 05 10:40:10 2016 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Tue Jul 05 10:40:10 2016 MANAGEMENT: >STATE:1467704410,ASSIGN_IP,,10.10.10.15,
Tue Jul 05 10:40:10 2016 open_tun, tt->ipv6=0
Tue Jul 05 10:40:10 2016 TAP-WIN32 device [Ethernet 3] opened: \\.\Global\{4323D808-83FC-4677-B23D-E857B51E3D8E}.tap
Tue Jul 05 10:40:10 2016 TAP-Windows Driver Version 9.21 
Tue Jul 05 10:40:10 2016 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.10.10.15/255.255.255.0 on interface {4323D808-83FC-4677-B23D-E857B51E3D8E} [DHCP-serv: 10.10.10.0, lease-time: 31536000]
Tue Jul 05 10:40:10 2016 Successful ARP Flush on interface [4] {4323D808-83FC-4677-B23D-E857B51E3D8E}
Tue Jul 05 10:40:15 2016 TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Tue Jul 05 10:40:15 2016 MANAGEMENT: >STATE:1467704415,ADD_ROUTES,,,
Tue Jul 05 10:40:15 2016 C:\Windows\system32\route.exe ADD 172.17.17.0 MASK 255.255.255.0 10.10.10.1
Tue Jul 05 10:40:15 2016 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4
Tue Jul 05 10:40:15 2016 Route addition via IPAPI succeeded [adaptive]
Tue Jul 05 10:40:15 2016 C:\Windows\system32\route.exe ADD 172.17.18.0 MASK 255.255.255.0 10.10.10.1
Tue Jul 05 10:40:15 2016 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4
Tue Jul 05 10:40:15 2016 Route addition via IPAPI succeeded [adaptive]
Tue Jul 05 10:40:15 2016 Initialization Sequence Completed
Tue Jul 05 10:40:15 2016 MANAGEMENT: >STATE:1467704415,CONNECTED,SUCCESS,10.10.10.15,37.139.40.253
Tue Jul 05 10:40:48 2016 C:\Windows\system32\route.exe DELETE 172.17.18.0 MASK 255.255.255.0 10.10.10.1
Tue Jul 05 10:40:48 2016 Route deletion via IPAPI succeeded [adaptive]
Tue Jul 05 10:40:48 2016 C:\Windows\system32\route.exe DELETE 172.17.17.0 MASK 255.255.255.0 10.10.10.1
Tue Jul 05 10:40:48 2016 Route deletion via IPAPI succeeded [adaptive]
Tue Jul 05 10:40:48 2016 Closing TUN/TAP interface
Tue Jul 05 10:40:48 2016 SIGTERM[hard,] received, process exiting
Tue Jul 05 10:40:48 2016 MANAGEMENT: >STATE:1467704448,EXITING,SIGTERM,,

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

Лог сервера 

Tue Jul  5 10:39:16 2016 us=658747 OpenVPN 2.3.4 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Nov 12 2015
Tue Jul  5 10:39:16 2016 us=658765 library versions: OpenSSL 1.0.1t  3 May 2016, LZO 2.08
Tue Jul  5 10:39:16 2016 us=658886 NOTE: when bridging your LAN adapter with the TAP adapter, note that the new bridge adapter will often take on its own IP address that is different from what the LAN adapter was previously set to
Tue Jul  5 10:39:16 2016 us=664670 PLUGIN_INIT: POST /usr/lib/openvpn/openvpn-auth-ldap.so '[/usr/lib/openvpn/openvpn-auth-ldap.so] [/etc/openvpn/ldap.conf]' intercepted=PLUGIN_AUTH_USER_PASS_VERIFY|PLUGIN_CLIENT_CONNECT|PLUGIN_CLIENT_DISCONNECT
Tue Jul  5 10:39:16 2016 us=665433 Diffie-Hellman initialized with 2048 bit key
Tue Jul  5 10:39:16 2016 us=666062 WARNING: file '/etc/openvpn/keys/VFA-VPNO-0001-V.key' is group or others accessible
Tue Jul  5 10:39:16 2016 us=666555 Control Channel Authentication: using '/etc/openvpn/keys/ta.key' as a OpenVPN static key file
Tue Jul  5 10:39:16 2016 us=666592 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jul  5 10:39:16 2016 us=666610 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jul  5 10:39:16 2016 us=666626 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1200)
Tue Jul  5 10:39:16 2016 us=666642 TLS-Auth MTU parms [ L:1291 D:168 EF:68 EB:0 ET:0 EL:0 ]
Tue Jul  5 10:39:16 2016 us=666673 Socket Buffers: R=[87380->131072] S=[16384->131072]
Tue Jul  5 10:39:16 2016 us=666958 ROUTE_GATEWAY 10.10.10.254/255.255.255.0 IFACE=br0 HWADDR=00:0c:29:44:9a:1f
Tue Jul  5 10:39:16 2016 us=666997 OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
Tue Jul  5 10:39:16 2016 us=667009 OpenVPN ROUTE: failed to parse/resolve route for host/network: 172.17.17.0
Tue Jul  5 10:39:16 2016 us=667021 OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
Tue Jul  5 10:39:16 2016 us=667032 OpenVPN ROUTE: failed to parse/resolve route for host/network: 172.17.18.0
Tue Jul  5 10:39:16 2016 us=667383 TUN/TAP device tap0 opened
Tue Jul  5 10:39:16 2016 us=667422 TUN/TAP TX queue length set to 100
Tue Jul  5 10:39:16 2016 us=667468 Data Channel MTU parms [ L:1291 D:1291 EF:59 EB:4 ET:32 EL:0 ]
Tue Jul  5 10:39:16 2016 us=670351 GID set to openvpn
Tue Jul  5 10:39:16 2016 us=670423 UID set to openvpn
Tue Jul  5 10:39:16 2016 us=670453 Listening for incoming TCP connection on [undef]
Tue Jul  5 10:39:16 2016 us=670483 TCPv4_SERVER link local (bound): [undef]
Tue Jul  5 10:39:16 2016 us=670498 TCPv4_SERVER link remote: [undef]
Tue Jul  5 10:39:16 2016 us=670517 MULTI: multi_init called, r=256 v=256
Tue Jul  5 10:39:16 2016 us=670612 IFCONFIG POOL: base=10.10.10.10 size=241, ipv6=0
Tue Jul  5 10:39:16 2016 us=670665 MULTI: TCP INIT maxclients=1024 maxevents=1028
Tue Jul  5 10:39:16 2016 us=670705 Initialization Sequence Completed
Tue Jul  5 10:40:34 2016 us=677724 MULTI: multi_create_instance called
Tue Jul  5 10:40:34 2016 us=678145 Re-using SSL/TLS context
Tue Jul  5 10:40:34 2016 us=678197 WARNING: normally if you use --mssfix and/or --fragment, you should also set --tun-mtu 1500 (currently it is 1200)
Tue Jul  5 10:40:34 2016 us=678587 Control Channel MTU parms [ L:1291 D:168 EF:68 EB:0 ET:0 EL:0 ]
Tue Jul  5 10:40:34 2016 us=678640 Data Channel MTU parms [ L:1291 D:1291 EF:59 EB:4 ET:32 EL:0 ]
Tue Jul  5 10:40:34 2016 us=678716 Local Options String: 'V4,dev-type tap,link-mtu 1291,tun-mtu 1232,proto TCPv4_SERVER,keydir 0,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-server'
Tue Jul  5 10:40:34 2016 us=678735 Expected Remote Options String: 'V4,dev-type tap,link-mtu 1291,tun-mtu 1232,proto TCPv4_CLIENT,keydir 1,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-client'
Tue Jul  5 10:40:34 2016 us=678774 Local Options hash (VER=V4): '21782a4c'
Tue Jul  5 10:40:34 2016 us=678799 Expected Remote Options hash (VER=V4): '4aed1d34'
Tue Jul  5 10:40:34 2016 us=678879 TCP connection established with [AF_INET]37.139.40.220:53498
Tue Jul  5 10:40:34 2016 us=678902 TCPv4_SERVER link local: [undef]
Tue Jul  5 10:40:34 2016 us=678919 TCPv4_SERVER link remote: [AF_INET]37.139.40.220:53498
Tue Jul  5 10:40:35 2016 us=672441 37.139.40.220:53498 TLS: Initial packet from [AF_INET]37.139.40.220:53498, sid=84b3d70c 5e211a9a
Tue Jul  5 10:40:35 2016 us=780834 37.139.40.220:53498 CRL CHECK OK: DC=LOCAL, DC=VIRTUALFORT, CN=VIRTUALFORT-VFA-DCOM-0001-V-CA
Tue Jul  5 10:40:35 2016 us=780983 37.139.40.220:53498 VERIFY OK: depth=1, DC=LOCAL, DC=VIRTUALFORT, CN=VIRTUALFORT-VFA-DCOM-0001-V-CA
Tue Jul  5 10:40:35 2016 us=783654 37.139.40.220:53498 CRL CHECK OK: CN=dkrinitsyn
Tue Jul  5 10:40:35 2016 us=783725 37.139.40.220:53498 VERIFY OK: depth=0, CN=dkrinitsyn
Tue Jul  5 10:40:35 2016 us=891161 37.139.40.220:53498 PLUGIN_CALL: POST /usr/lib/openvpn/openvpn-auth-ldap.so/PLUGIN_AUTH_USER_PASS_VERIFY status=0
Tue Jul  5 10:40:35 2016 us=891270 37.139.40.220:53498 TLS: Username/Password authentication succeeded for username 'dkrinitsyn' [CN SET]
Tue Jul  5 10:40:35 2016 us=891440 37.139.40.220:53498 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Tue Jul  5 10:40:35 2016 us=891465 37.139.40.220:53498 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jul  5 10:40:35 2016 us=891543 37.139.40.220:53498 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Tue Jul  5 10:40:35 2016 us=891566 37.139.40.220:53498 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Jul  5 10:40:35 2016 us=932054 37.139.40.220:53498 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Tue Jul  5 10:40:35 2016 us=932121 37.139.40.220:53498 [dkrinitsyn] Peer Connection Initiated with [AF_INET]37.139.40.220:53498
Tue Jul  5 10:40:35 2016 us=938375 dkrinitsyn/37.139.40.220:53498 OPTIONS IMPORT: reading client specific options from: /etc/openvpn/ccd/dkrinitsyn
Tue Jul  5 10:40:35 2016 us=949183 dkrinitsyn/37.139.40.220:53498 PLUGIN_CALL: POST /usr/lib/openvpn/openvpn-auth-ldap.so/PLUGIN_CLIENT_CONNECT status=0
Tue Jul  5 10:40:35 2016 us=949237 dkrinitsyn/37.139.40.220:53498 OPTIONS IMPORT: reading client specific options from: /tmp/openvpn_cc_c9a37351d98f47e888290a28b0663f48.tmp
Tue Jul  5 10:40:37 2016 us=648181 dkrinitsyn/37.139.40.220:53498 PUSH: Received control message: 'PUSH_REQUEST'
Tue Jul  5 10:40:37 2016 us=648227 dkrinitsyn/37.139.40.220:53498 send_push_reply(): safe_cap=940
Tue Jul  5 10:40:37 2016 us=648267 dkrinitsyn/37.139.40.220:53498 SENT CONTROL [dkrinitsyn]: 'PUSH_REPLY,route 172.17.17.0 255.255.255.0,route 172.17.18.0 255.255.255.0,route-gateway 10.10.10.1,ping 10,ping-restart 900,ifconfig 10.10.10.15 255.255.255.0' (status=1)
Tue Jul  5 10:40:37 2016 us=769904 dkrinitsyn/37.139.40.220:53498 MULTI: Learn: 00:ff:43:23:d8:08 -> dkrinitsyn/37.139.40.220:53498
Tue Jul  5 10:41:15 2016 us=470418 dkrinitsyn/37.139.40.220:53498 Connection reset, restarting [-1]
Tue Jul  5 10:41:15 2016 us=470529 dkrinitsyn/37.139.40.220:53498 SIGUSR1[soft,connection-reset] received, client-instance restarting
Tue Jul  5 10:41:15 2016 us=479015 PLUGIN_CALL: POST /usr/lib/openvpn/openvpn-auth-ldap.so/PLUGIN_CLIENT_DISCONNECT status=0
Tue Jul  5 10:41:15 2016 us=479469 TCP/UDP: Closing socket

PS: Вот кстати одно из доказательств того, что пакеты до циски доходят и она видит IP-адрес клиента OpenVPN. Естественно проблема не в acl, я их выключил. 

Jul  5 07:40:43.310: %SEC-6-IPACCESSLOGDP: list VFA-VPNO-0001-V-out denied icmp 172.17.17.1 -> 10.10.10.15 (0/0), 1 packet
Jul  5 07:40:49.718: %SEC-6-IPACCESSLOGDP: list VFA-VPNO-0001-V-out denied icmp 172.17.17.2 -> 10.10.10.15 (0/0), 1 packet

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

И при такой конфигурации у тебя пакеты от openvpn клиентов к хостам из сетей 172.17.17.0/24 ... идут, а обратно нет?

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

Сам в шоке, но да :) С циски OpenVPN сервер пингуется, клиенты нет. 

ping 10.10.10.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

ping 10.10.10.15
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.10.15, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

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

Я добавил более точный маршрут и все заработало 

ip route 10.10.10.15 255.255.255.255 10.10.10.1 permanent
Но это не вариант на каждого клиента писать маршрут.

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

А попробуй во время пинга openvpn клиента с cisco, посмотреть tcpdump-ом на openvpn сервере интерфейс tap0 

tcpdump -i tap0

rumgot ★★★★★
()
Ответ на: комментарий от rumgot 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:00:00.000000 IP 10.10.10.254 > 10.10.10.15: ICMP echo request, id 8, seq 0, length 80
00:00:00.000071 IP 10.10.10.254 > 10.10.10.15: ICMP echo request, id 8, seq 0, length 80
00:00:01.997581 IP 10.10.10.254 > 10.10.10.15: ICMP echo request, id 8, seq 1, length 80
00:00:00.000068 IP 10.10.10.1 > 10.10.10.254: ICMP redirect 10.10.10.15 to host 10.10.10.15, length 108
00:00:00.000032 IP 10.10.10.254 > 10.10.10.15: ICMP echo request, id 8, seq 1, length 80
00:00:01.999849 IP 10.10.10.254 > 10.10.10.15: ICMP echo request, id 8, seq 2, length 80
00:00:00.000075 IP 10.10.10.1 > 10.10.10.254: ICMP redirect 10.10.10.15 to host 10.10.10.15, length 108
00:00:00.000032 IP 10.10.10.254 > 10.10.10.15: ICMP echo request, id 8, seq 2, length 80
00:00:01.999909 IP 10.10.10.254 > 10.10.10.15: ICMP echo request, id 8, seq 3, length 80
00:00:00.000068 IP 10.10.10.1 > 10.10.10.254: ICMP redirect 10.10.10.15 to host 10.10.10.15, length 108
00:00:00.000032 IP 10.10.10.254 > 10.10.10.15: ICMP echo request, id 8, seq 3, length 80
00:00:01.999764 IP 10.10.10.254 > 10.10.10.15: ICMP echo request, id 8, seq 4, length 80
00:00:00.000068 IP 10.10.10.1 > 10.10.10.254: ICMP redirect 10.10.10.15 to host 10.10.10.15, length 108
00:00:00.000030 IP 10.10.10.254 > 10.10.10.15: ICMP echo request, id 8, seq 4, length 80
enterdv
() автор топика
Ответ на: комментарий от enterdv

Мне вот интересно, вы специально выборочно сообщения читаете в своей же теме? Вам вот про это «route-gateway» уже несколько раз написали.
ЗЫ Чего-то я не увидел в вашем «доказательстве» пакетов от 10.10.10.15

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

Это ведь без добавления специального маршрута к 10.10.10.15 на cisco? А можешь теперь сделать тоже tcpdump-ом на хосте 10.10.10.15 ?

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

Да специально пропускаю Ваши сообщения. Уже во втором сообщении выяснили, что route-gateway не нужен.

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

Да, нужно было без добавленного отдельного маршрута. Чтобы посмотреть, доходят ли пакеты до OpenVPN сервера.

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

Прошу прощения за долгий ответ, пришлось срочно уехать. Без специального маршрута: 

listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:00:00.000000 IP 10.10.10.1 > 10.10.10.15: ICMP redirect 172.17.18.1 to host 10.10.10.254, length 60
Я не знаю при чем тут 172.17.18.1, это вообще терминальный сервер.

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

Это tcpdump -i br0 на OpenVPN сервере при выполнении пинга с cisco(без специального маршрута)?
А у тебя на OpenVPN сервере iptables ничего не подменяет часом(в смысле SNAT или MASQUERADE)?

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

Что-то я уже перестал понимать. Постараюсь в ближайшее время поднять похожую виртуальную сеть и тогда отвечу, если еще актуально будет.

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

Я вот тут - OpenVPN bridge-mode не видно локальную сеть прочитал про почти аналогичную проблему и там человек пишет про включение спуфинга. У меня кстати OpenVPN сервер на ESXi, но и нигде не найду как это включается.

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

У меня взрывается мозг! Смотрим arp-кеш на Cisco и видим: 

Internet  10.10.10.15 00ff.4323.d808  ARPA GigabitEthernet0/2.1010
Смотрим arp на сервере OpenVPN и видим: 
(10.10.10.15) at 00:ff:43:23:d8:08 [ether] on br0
Пингуем с Cisco клиента 10.10.10.15 - не пингуется. Смотрим на сервере OpenVPN tcpdump-ом ICMP пакеты на интерфейсе br0 - нету!

Как так-то?

Пингуем с Cisco сервер OpenVPN - пингуется, смотрим tcpdump-ом: 

00:00:00.000000 IP 10.10.10.254 > 10.10.10.1: ICMP echo request, id 14, seq 0, length 80
00:00:00.000044 IP 10.10.10.1 > 10.10.10.254: ICMP echo reply, id 14, seq 0, length 80
00:00:00.000666 IP 10.10.10.254 > 10.10.10.1: ICMP echo request, id 14, seq 1, length 80
00:00:00.000031 IP 10.10.10.1 > 10.10.10.254: ICMP echo reply, id 14, seq 1, length 80
00:00:00.000571 IP 10.10.10.254 > 10.10.10.1: ICMP echo request, id 14, seq 2, length 80
00:00:00.000016 IP 10.10.10.1 > 10.10.10.254: ICMP echo reply, id 14, seq 2, length 80
00:00:00.000560 IP 10.10.10.254 > 10.10.10.1: ICMP echo request, id 14, seq 3, length 80
00:00:00.000016 IP 10.10.10.1 > 10.10.10.254: ICMP echo reply, id 14, seq 3, length 80
00:00:00.000543 IP 10.10.10.254 > 10.10.10.1: ICMP echo request, id 14, seq 4, length 80
00:00:00.000014 IP 10.10.10.1 > 10.10.10.254: ICMP echo reply, id 14, seq 4, length 80

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

Извини, пока не могу настроить твою схему, много работы. Позже. А нет ли возможности у тебя вместо cisco временно поставить какой-нибудь комп с адресом 10.10.10.254/24 ?

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

Есть, просто я не понимаю, что это изменит. Я пару дней назад баловался разными параметрами ядра, в том числе этими 

net.bridge.bridge-nf-call-arptables
net.bridge.bridge-nf-call-ip6tables
net.bridge.bridge-nf-call-iptables
и в какой-то момент у меня все заработало нормально, без маршрута, но потом умерло после ребута и больше я этого не добился :)

enterdv
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Ротация логов apache
Admin
Как быстро сохранить бэкап одновременно на два разных диска локальной машины? →