OpenVPN в режиме bridge (клиент видит сервер, но не видит сеть за ним)

VZhiK84 · Сообщение **VZhiK84** » 03.11.2009 14:31

Предыстория:
Есть локалка (192.168.8.0/24). Шлюзом в локалке 192.168.8.2, внешний IP шлюза 1.1.1.1. Охота попадать в эту сеть снаружи, причем без роутинга попадать напрямую в локалку. Для этого я поднял на SLES11 сервак, имеющий внутренний IP 192.168.8.20 и внешний 2.2.2.2, на него поставил openvpn и bridgeutils. Конфиги почти по-умолчанию, проблема такая:
соединение нормально устанавливается, клиент видит сервер, сервер видит клиента, но клиент не видит всей локальной сети

Лог сервера:

Код: Выделить всё

vpn:/etc/openvpn # openvpn server.conf
Tue Nov  3 22:32:21 2009 OpenVPN 2.0.9 i586-suse-linux [SSL] [LZO] [EPOLL] built on Feb 25 2009
Tue Nov  3 22:32:21 2009 Diffie-Hellman initialized with 1024 bit key
Tue Nov  3 22:32:21 2009 TLS-Auth MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Nov  3 22:32:21 2009 TUN/TAP device tap0 opened
Tue Nov  3 22:32:21 2009 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Tue Nov  3 22:32:21 2009 GID set to nobody
Tue Nov  3 22:32:21 2009 UID set to nobody
Tue Nov  3 22:32:21 2009 UDPv4 link local (bound): 2.2.2.2:1194
Tue Nov  3 22:32:21 2009 UDPv4 link remote: [undef]
Tue Nov  3 22:32:21 2009 MULTI: multi_init called, r=256 v=256
Tue Nov  3 22:32:21 2009 IFCONFIG POOL: base=192.168.8.60 size=7
Tue Nov  3 22:32:21 2009 IFCONFIG POOL LIST
Tue Nov  3 22:32:21 2009 Initialization Sequence Completed
Tue Nov  3 22:32:56 2009 MULTI: multi_create_instance called
Tue Nov  3 22:32:56 2009 172.16.10.28:44392 Re-using SSL/TLS context
Tue Nov  3 22:32:56 2009 172.16.10.28:44392 LZO compression initialized
Tue Nov  3 22:32:56 2009 172.16.10.28:44392 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Nov  3 22:32:56 2009 172.16.10.28:44392 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Tue Nov  3 22:32:56 2009 172.16.10.28:44392 Local Options hash (VER=V4): 'f7df56b8'
Tue Nov  3 22:32:56 2009 172.16.10.28:44392 Expected Remote Options hash (VER=V4): 'd79ca330'
Tue Nov  3 22:32:56 2009 172.16.10.28:44392 TLS: Initial packet from 172.16.10.28:44392, sid=f05237c9 2de0b4fd
Tue Nov  3 22:32:56 2009 172.16.10.28:44392 VERIFY OK: depth=1, /C=RU/ST=PK/L=PETROPAVLOVSKKAMCHATSKY/O=PKF_FGUP_CentrInform/CN=firewall/emailAddress=ca@ххх.ru
Tue Nov  3 22:32:56 2009 172.16.10.28:44392 VERIFY OK: depth=0, /C=RU/ST=PK/O=PKF_FGUP_CentrInform/CN=vzhikbook/emailAddress=ca@ххх.ru
Tue Nov  3 22:32:56 2009 172.16.10.28:44392 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Nov  3 22:32:56 2009 172.16.10.28:44392 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Nov  3 22:32:56 2009 172.16.10.28:44392 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Nov  3 22:32:56 2009 172.16.10.28:44392 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Nov  3 22:32:56 2009 172.16.10.28:44392 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Tue Nov  3 22:32:56 2009 172.16.10.28:44392 [vzhikbook] Peer Connection Initiated with 172.16.10.28:44392
Tue Nov  3 22:32:56 2009 vzhikbook/172.16.10.28:44392 OPTIONS IMPORT: reading client specific options from: ccd/vzhikbook
Tue Nov  3 22:32:57 2009 vzhikbook/172.16.10.28:44392 PUSH: Received control message: 'PUSH_REQUEST'
Tue Nov  3 22:32:57 2009 vzhikbook/172.16.10.28:44392 SENT CONTROL [vzhikbook]: 'PUSH_REPLY,route-gateway 192.168.8.20,ping 10,ping-restart 120,ifconfig 192.168.8.65 255.255.255.0' (status=1)
Tue Nov  3 22:32:57 2009 vzhikbook/172.16.10.28:44392 MULTI: Learn: a6:47:a0:47:33:61 -> vzhikbook/172.16.10.28:44392

Лог клиента:

Код: Выделить всё

vzhikbook:/etc/openvpn # openvpn client.conf
Tue Nov  3 22:33:57 2009 OpenVPN 2.0.9 i586-suse-linux [SSL] [LZO] [EPOLL] built on Dec  3 2008
Tue Nov  3 22:33:57 2009 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA.  OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Tue Nov  3 22:33:57 2009 LZO compression initialized
Tue Nov  3 22:33:57 2009 Control Channel MTU parms [ L:1574 D:138 EF:38 EB:0 ET:0 EL:0 ]
Tue Nov  3 22:33:57 2009 Data Channel MTU parms [ L:1574 D:1450 EF:42 EB:135 ET:32 EL:0 AF:3/1 ]
Tue Nov  3 22:33:57 2009 Local Options hash (VER=V4): 'd79ca330'
Tue Nov  3 22:33:57 2009 Expected Remote Options hash (VER=V4): 'f7df56b8'
Tue Nov  3 22:33:57 2009 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Tue Nov  3 22:33:57 2009 UDPv4 link local: [undef]
Tue Nov  3 22:33:57 2009 UDPv4 link remote: 2.2.2.2:1194
Tue Nov  3 22:33:57 2009 TLS: Initial packet from 2.2.2.2:1194, sid=9203445a 170272df
Tue Nov  3 22:33:57 2009 VERIFY OK: depth=1, /C=RU/ST=PK/L=PETROPAVLOVSKKAMCHATSKY/O=PKF_FGUP_CentrInform/CN=firewall/emailAddress=ca@ххх.ru
Tue Nov  3 22:33:57 2009 VERIFY OK: nsCertType=SERVER
Tue Nov  3 22:33:57 2009 VERIFY OK: depth=0, /C=RU/ST=PK/O=PKF_FGUP_CentrInform/CN=atlaskam/emailAddress=ca@ххх.ru
Tue Nov  3 22:33:57 2009 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Nov  3 22:33:57 2009 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Nov  3 22:33:57 2009 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Tue Nov  3 22:33:57 2009 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Tue Nov  3 22:33:57 2009 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Tue Nov  3 22:33:57 2009 [atlaskam] Peer Connection Initiated with 2.2.2.2:1194
Tue Nov  3 22:33:58 2009 SENT CONTROL [atlaskam]: 'PUSH_REQUEST' (status=1)
Tue Nov  3 22:33:58 2009 PUSH: Received control message: 'PUSH_REPLY,route-gateway 192.168.8.20,ping 10,ping-restart 120,ifconfig 192.168.8.65 255.255.255.0'
Tue Nov  3 22:33:58 2009 OPTIONS IMPORT: timers and/or timeouts modified
Tue Nov  3 22:33:58 2009 OPTIONS IMPORT: --ifconfig/up options modified
Tue Nov  3 22:33:58 2009 OPTIONS IMPORT: route options modified
Tue Nov  3 22:33:58 2009 TUN/TAP device tap0 opened
Tue Nov  3 22:33:58 2009 /bin/ip link set dev tap0 up mtu 1500
Tue Nov  3 22:33:58 2009 /bin/ip addr add dev tap0 192.168.8.65/24 broadcast 192.168.8.255
Tue Nov  3 22:33:58 2009 GID set to nobody
Tue Nov  3 22:33:58 2009 UID set to nobody
Tue Nov  3 22:33:58 2009 Initialization Sequence Completed

Интерфейсы сервака:

Код: Выделить всё

vpn:/etc/openvpn # ifconfig -a
br0       Link encap:Ethernet  HWaddr 00:0C:29:A5:71:8A
          inet addr:192.168.8.20  Bcast:192.168.8.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2407 errors:0 dropped:0 overruns:0 frame:0
          TX packets:397 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:247329 (241.5 Kb)  TX bytes:146783 (143.3 Kb)

eth0      Link encap:Ethernet  HWaddr 00:0C:29:A5:71:8A
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:2604 errors:0 dropped:0 overruns:0 frame:0
          TX packets:406 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:309964 (302.6 Kb)  TX bytes:147161 (143.7 Kb)

eth1      Link encap:Ethernet  HWaddr 00:0C:29:A5:71:94
          inet addr:2.2.2.2 Bcast:2.2.2.127  Mask:255.255.255.224
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1564 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1860 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:161037 (157.2 Kb)  TX bytes:359421 (350.9 Kb)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:100 (100.0 b)  TX bytes:100 (100.0 b)

tap0      Link encap:Ethernet  HWaddr 3A:C3:1D:06:42:26
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:69 errors:0 dropped:0 overruns:0 frame:0
          TX packets:940 errors:0 dropped:287 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:11539 (11.2 Kb)  TX bytes:66966 (65.3 Kb)

Интерфесы клиента:

Код: Выделить всё

vzhikbook:/home/vzhik # ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:26:18:9F:E3:F3
          inet addr:172.16.10.28  Bcast:172.16.255.255  Mask:255.255.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:519817 errors:0 dropped:0 overruns:0 frame:0
          TX packets:36532 errors:0 dropped:0 overruns:0 carrier:2
          collisions:0 txqueuelen:1000
          RX bytes:47439735 (45.2 Mb)  TX bytes:3491313 (3.3 Mb)
          Interrupt:219

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:86 errors:0 dropped:0 overruns:0 frame:0
          TX packets:86 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:8700 (8.4 Kb)  TX bytes:8700 (8.4 Kb)

tap0      Link encap:Ethernet  HWaddr D2:FC:0A:2B:9E:62
          inet addr:192.168.8.65  Bcast:192.168.8.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:964 (964.0 b)  TX bytes:3242 (3.1 Kb)

vboxnet0  Link encap:Ethernet  HWaddr 0A:00:27:00:00:00
          UP BROADCAST RUNNING MULTICAST  MTU:1500  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:1000
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

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

Код: Выделить всё

local 2.2.2.2
port 1194
proto udp
dev tap0
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/atlaskam.crt
key /etc/openvpn/keys/atlaskam.key  # This file should be kept secret
dh /etc/openvpn/keys/dh1024.pem
ifconfig-pool-persist ipp.txt
server-bridge 192.168.8.20 255.255.255.0 192.168.8.60 192.168.8.66
client-config-dir ccd
client-to-client
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3

Конфиг клиента:

Код: Выделить всё

client

dev tap
proto udp
remote 2.2.2.2 1194
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/vzhikbook.crt
key /etc/openvpn/keys/vzhikbook.key
ns-cert-type server
comp-lzo
verb 3

На сервере в cdd есть файл vzhikbook с таким содержимым:

Код: Выделить всё

ifconfig-push 192.168.8.65 255.255.255.0

Перед запуском опенвпна запускаю скрипт бридж старт:

Код: Выделить всё

br="br0"

tap="tap0"
eth="eth0"
eth_ip="192.168.8.20"
eth_netmask="255.255.255.0"
eth_broadcast="192.168.8.255"

for t in $tap; do
    openvpn --mktun --dev $t
done

brctl addbr $br
brctl addif $br $eth

for t in $tap; do
    brctl addif $br $t
done

for t in $tap; do
    ifconfig $t 0.0.0.0 promisc up
done

ifconfig $eth 0.0.0.0 promisc up

ifconfig $br $eth_ip netmask $eth_netmask broadcast $eth_broadcast

Немножко логов снифера на клиенте:

Код: Выделить всё

vzhikbook:/home/vzhik # tshark -i tap0
Running as user "root" and group "root". This could be dangerous.
Capturing on tap0
  0.000000 Supermic_b8:b6:e2 -> Broadcast    ARP Gratuitous ARP for 192.168.8.235 (Request)
  2.079925 Supermic_b8:b6:e2 -> Broadcast    ARP Gratuitous ARP for 192.168.8.235 (Request)
  4.160066 Supermic_b8:b6:e2 -> Broadcast    ARP Gratuitous ARP for 192.168.8.235 (Request)
  6.240232 Supermic_b8:b6:e2 -> Broadcast    ARP Gratuitous ARP for 192.168.8.235 (Request)
  8.320414 Supermic_b8:b6:e2 -> Broadcast    ARP Gratuitous ARP for 192.168.8.235 (Request)
 10.410574 Supermic_b8:b6:e2 -> Broadcast    ARP Gratuitous ARP for 192.168.8.235 (Request)
 11.538283 00000000.0010f301d987 -> 00000000.ffffffffffff IPX SAP General Response
 11.713454 192.168.8.65 -> 192.168.8.255 NBNS Registration NB VZHIKBOOK<20>
 11.713479 192.168.8.65 -> 192.168.8.255 NBNS Registration NB VZHIKBOOK<03>
 11.713495 192.168.8.65 -> 192.168.8.255 NBNS Registration NB VZHIKBOOK<00>
 11.713513 192.168.8.65 -> 192.168.8.255 NBNS Registration NB INFORM<00>
 11.713529 192.168.8.65 -> 192.168.8.255 NBNS Registration NB INFORM<1e>
 12.500681 Supermic_b8:b6:e2 -> Broadcast    ARP Gratuitous ARP for 192.168.8.235 (Request)
 12.714311 192.168.8.65 -> 192.168.8.255 BROWSER Host Announcement VZHIKBOOK, Workstation, Server, Print Queue Server, Xenix Server, NT Workstation, NT Server, Potential Browser, Unknown server type:23
 13.713315 192.168.8.65 -> 192.168.8.255 NBNS Registration NB VZHIKBOOK<20>
 13.713350 192.168.8.65 -> 192.168.8.255 NBNS Registration NB VZHIKBOOK<03>
 13.713370 192.168.8.65 -> 192.168.8.255 NBNS Registration NB VZHIKBOOK<00>
 13.713391 192.168.8.65 -> 192.168.8.255 NBNS Registration NB INFORM<00>
 13.713409 192.168.8.65 -> 192.168.8.255 NBNS Registration NB INFORM<1e>
 14.590884 Supermic_b8:b6:e2 -> Broadcast    ARP Gratuitous ARP for 192.168.8.235 (Request)
 14.713302 192.168.8.65 -> 192.168.8.255 NBNS Registration NB VZHIKBOOK<20>
 14.713322 192.168.8.65 -> 192.168.8.255 NBNS Registration NB VZHIKBOOK<03>
 14.713333 192.168.8.65 -> 192.168.8.255 NBNS Registration NB VZHIKBOOK<00>
 14.713344 192.168.8.65 -> 192.168.8.255 NBNS Registration NB INFORM<00>
 14.713355 192.168.8.65 -> 192.168.8.255 NBNS Registration NB INFORM<1e>
 15.713309 192.168.8.65 -> 192.168.8.255 NBNS Registration NB VZHIKBOOK<20>
 15.713329 192.168.8.65 -> 192.168.8.255 NBNS Registration NB VZHIKBOOK<03>
 15.713341 192.168.8.65 -> 192.168.8.255 NBNS Registration NB VZHIKBOOK<00>
 15.713353 192.168.8.65 -> 192.168.8.255 NBNS Registration NB INFORM<00>
 15.713364 192.168.8.65 -> 192.168.8.255 NBNS Registration NB INFORM<1e>
 16.681100 Supermic_b8:b6:e2 -> Broadcast    ARP Gratuitous ARP for 192.168.8.235 (Request)
 17.899509 AsustekC_25:79:d1 -> Broadcast    ARP Who has 192.168.8.231?  Tell 192.168.8.4
 18.771242 Supermic_b8:b6:e2 -> Broadcast    ARP Gratuitous ARP for 192.168.8.235 (Request)
 20.861532 Supermic_b8:b6:e2 -> Broadcast    ARP Gratuitous ARP for 192.168.8.235 (Request)
 22.951531 Supermic_b8:b6:e2 -> Broadcast    ARP Gratuitous ARP for 192.168.8.235 (Request)
 25.041646 Supermic_b8:b6:e2 -> Broadcast    ARP Gratuitous ARP for 192.168.8.235 (Request)
 27.131865 Supermic_b8:b6:e2 -> Broadcast    ARP Gratuitous ARP for 192.168.8.235 (Request)
 29.222089 Supermic_b8:b6:e2 -> Broadcast    ARP Gratuitous ARP for 192.168.8.235 (Request)
 31.312752 Supermic_b8:b6:e2 -> Broadcast    ARP Gratuitous ARP for 192.168.8.235 (Request)
 33.424056 Supermic_b8:b6:e2 -> Broadcast    ARP Gratuitous ARP for 192.168.8.235 (Request)
 34.899381 Vmware_38:30:3c -> Broadcast    ARP Who has 192.168.8.7?  Tell 192.168.8.9
 35.512550 Supermic_b8:b6:e2 -> Broadcast    ARP Gratuitous ARP for 192.168.8.235 (Request)
 37.261239 a6:47:a0:47:33:61 -> Broadcast    ARP Who has 192.168.8.2?  Tell 192.168.8.65
 37.592673 Supermic_b8:b6:e2 -> Broadcast    ARP Gratuitous ARP for 192.168.8.235 (Request)
 38.257239 a6:47:a0:47:33:61 -> Broadcast    ARP Who has 192.168.8.2?  Tell 192.168.8.65
 39.257258 a6:47:a0:47:33:61 -> Broadcast    ARP Who has 192.168.8.2?  Tell 192.168.8.65
 39.673039 Supermic_b8:b6:e2 -> Broadcast    ARP Gratuitous ARP for 192.168.8.235 (Request)
 40.277256 a6:47:a0:47:33:61 -> Broadcast    ARP Who has 192.168.8.2?  Tell 192.168.8.65
 41.277239 a6:47:a0:47:33:61 -> Broadcast    ARP Who has 192.168.8.2?  Tell 192.168.8.65
 41.753190 Supermic_b8:b6:e2 -> Broadcast    ARP Gratuitous ARP for 192.168.8.235 (Request)
 42.277241 a6:47:a0:47:33:61 -> Broadcast    ARP Who has 192.168.8.2?  Tell 192.168.8.65
 42.371251 AsustekC_25:79:d1 -> Broadcast    ARP Who has 192.168.8.8?  Tell 192.168.8.4
 43.833403 Supermic_b8:b6:e2 -> Broadcast    ARP Gratuitous ARP for 192.168.8.235 (Request)
 45.913506 Supermic_b8:b6:e2 -> Broadcast    ARP Gratuitous ARP for 192.168.8.235 (Request)
 46.983957 00:25:84:bd:81:40 -> CDP/VTP/DTP/PAgP/UDLD CDP Device ID: yourname.yourdomain.com  Port ID: FastEthernet0/0
 47.993677 Supermic_b8:b6:e2 -> Broadcast    ARP Gratuitous ARP for 192.168.8.235 (Request)
 50.073949 Supermic_b8:b6:e2 -> Broadcast    ARP Gratuitous ARP for 192.168.8.235 (Request)
 50.959101 Vmware_41:ba:31 -> Broadcast    ARP Who has 192.168.8.2?  Tell 192.168.8.80
 52.154112 Supermic_b8:b6:e2 -> Broadcast    ARP Gratuitous ARP for 192.168.8.235 (Request)

192.168.8.20 и 192.168.8.65 пингуют друг друга без проблем. 192.168.8.20 пингует любые хосты, 192.168.8.65 ничего не может пропинговать.

Потребуются ли еще какие-нибудь данные? Как сделать, чтобы клиент видел всю сеть 192.168.8.0/24?

Goodvin · Сообщение **Goodvin** » 03.11.2009 14:51

ccd-файлы на сервере имеются для этого клиента ?
Как Вы клиенту передает таблицу маршрутов, чтобы он знал через какой шлюз слать пакеты в Вашу локальную сеть ?

VZhiK84 писал(а): ↑
03.11.2009 14:31
На сервере в cdd есть файл vzhikbook с таким содержимым:
Код: Выделить всё
ifconfig-push 192.168.8.65 255.255.255.0

Может быть здесь нужно ccd вместо cdd ?

А куда идёт traceroute с клиента, если отправить его в Вашу локальную сеть ?

VZhiK84 · Сообщение **VZhiK84** » 03.11.2009 15:21

Да, ccd а не cdd, опечатка.

Как Вы клиенту передает таблицу маршрутов, чтобы он знал через какой шлюз слать пакеты в Вашу локальную сеть ?

Зачем клиенту передавать таблицу мартшрутов если он находится в одной сети с другими компами (интерфейс tap0 с ip 192.168.8.65)?

Код: Выделить всё

vzhikbook:/home/vzhik # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.8.0     0.0.0.0         255.255.255.0   U     0      0        0 tap0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
172.16.0.0      0.0.0.0         255.255.0.0     U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         172.16.253.1    0.0.0.0         UG    0      0        0 eth0


vzhikbook:/home/vzhik # traceroute 192.168.8.4
traceroute to 192.168.8.4 (192.168.8.4), 30 hops max, 40 byte packets using UDP
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  192.168.8.65 (192.168.8.65)(H!)  2882.993 ms (H!)  2875.999 ms (H!)  2868.007 ms

Goodvin · Сообщение **Goodvin** » 03.11.2009 15:25

VZhiK84 писал(а): ↑
03.11.2009 15:21
Да, ccd а не cdd, опечатка.

Как Вы клиенту передает таблицу маршрутов, чтобы он знал через какой шлюз слать пакеты в Вашу локальную сеть ?

Зачем клиенту передавать таблицу мартшрутов если он находится в одной сети с другими компами (интерфейс tap0 с ip 192.168.8.65)?

А Вы уверены, что пакеты для Вашей локальной сети уходят с этого интерфейса tap0?

Покажите таблицу маршрутов клиента после поднятия tap0 и так проверьте traceroute с клиента в локальную сеть.

VZhiK84 · Сообщение **VZhiK84** » 03.11.2009 16:02

Ответил чуть выше. Клиент видит широковещательные пакеты в сети, а так же попытки пропинговать хосты локалки. Проблема по ходу именно с возвратом пакетов на 192.168.8.65. Кажется, что бридж неправильно работает и пакеты уходят вникуда.

step_slim · Сообщение **step_slim** » 03.11.2009 16:03

А если не секрет, то почему Вы так не хотите использовать таблицу маршрутизации?? Вы пытаетесь устроить соединение "Точка-на-Точку" с расшареной сетью, я думаю Вам по любому нужно передать таблицу маршрутизации, либо в ручную добавить роут с удалённым интерфейсом, даже если у Вас компы находятся в одной сети. Подключение ведь не постоянно, а если учесть (по модели OSI) адресация у Вас ручная и обновления адресов устройств в сети следовательно ручное. Так что вот поэтому клиент и сервер видят и пингуются на друг -друга. Если бы у Вас было что клиент и сервер на ручной адресации, а от сервера в сети по DHCP, то у Вас бы не возникло такой проблемы. Либо добавляйте "широковещательный маршрут" на всю расшаренную сеть, либо сделайте получения адресации в расшареной сети автоматически.

Сообщение **serzh-z** » 03.11.2009 16:04

VZhiK84 писал(а): ↑
03.11.2009 14:31
соединение нормально устанавливается, клиент видит сервер, сервер видит клиента, но клиент не видит всей локальной сети

В файрволе, который на роутере, нужно добавить правило для форвардинга в/из локалки.

http://www.openvpn.net/index.php/open-sour...tion/howto.html

В моём случае (при использовании TUN), хватило этого:

iptables -I FORWARD -i tun+ -o br-lan -j ACCEPT
iptables -I FORWARD -i br-lan -o tun+ -j ACCEPT

rm_ · Сообщение **rm_** » 03.11.2009 17:44

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

Безотносительно этого, я бы посоветовал перейти на tun. Всё-таки на уровне таблиц маршрутизации, трейсов и пингов отлаживать это дело было бы как-то проще, чем на уровне Ethernet'овских ARP-запросов.

step_slim · Сообщение **step_slim** » 03.11.2009 23:27

rm_ писал(а): ↑
03.11.2009 17:44
Мда, похоже некоторые из отвечающих весьма слабо представляют себе, что такое tap-режим OpenVPN, и зачем у вас сделан бридж br0.

Безотносительно этого, я бы посоветовал перейти на tun. Всё-таки на уровне таблиц маршрутизации, трейсов и пингов отлаживать это дело было бы как-то проще, чем на уровне Ethernet'овских ARP-запросов.

Ну если Вы относительно меня, то я обсалютно не представляю как это на Linux настраивается, ибо не сталкивался, но как это должно работать вообще в сети отлично понимаю. Так как не зря имею сертификат по Cisco.

VZhiK84 · Сообщение **VZhiK84** » 05.11.2009 01:53

Поставлю вопрос по другому: http://www.openvpn.net/index.php/open-sour...t-bridging.html
В этом мануале описано как получить доступ только к серверу? Зачем тогда вообще давать IP локальной сети VPN-клиенту? Может все же есть возможность видеть удаленному клиенту локалку?

rm_ · Сообщение **rm_** » 05.11.2009 07:33

VZhiK84 писал(а): ↑
05.11.2009 01:53
Поставлю вопрос по другому: http://www.openvpn.net/index.php/open-sour...t-bridging.html
В этом мануале описано как получить доступ только к серверу? Зачем тогда вообще давать IP локальной сети VPN-клиенту? Может все же есть возможность видеть удаленному клиенту локалку?

Возможность есть, и более того, судя по представленным конфигам у Вас "всё должно работать", и почему не работает, сказать сложно.

VZhiK84 · Сообщение **VZhiK84** » 05.11.2009 10:09

Значит осталось найти того, у кого это работает на suse

Все же подозреваю, что некорректно работает bridgeutils на sles11 или надо что-то дописать в конфиг СусеФайрвола (и с отключенным и с включенным файрволом не работает)

step_slim · Сообщение **step_slim** » 05.11.2009 10:26

И так господа, посидел немножко, посоветовался со спецами и вот к чему пришли:
1. Конфиг сервера (щем вот эту строчку) "Client-to-client" я по моему писал Вы про соедениене "точка-точка"- перечетайти ещё раз тип соединение, где о какой локальной сети идёт речь?? У Вас настройки на соелдинение только двух железяк.
2. Используйте любой софтверный маршрутизатор, бриджем Вам не выползти, поясняю почему: Бриндж - устройство работающее по интерфейсам (мак адресам) как он у Вас по Вашему будет маршрутизировать пакеты из 2х сетей, что бы Вы могли получить доступ к локалке???
3. "192.168.8.20 и 192.168.8.65 пингуют друг друга без проблем. 192.168.8.20 пингует любые хосты, 192.168.8.65 ничего не может пропинговать."- ну естественно, когда Вы пытаетесь пинговать с адреса 192.168.8.65 у Вас всё обрывается на адресе 192.168.8.20 (далее этого адреса маршруты неизвестны) потому что у Вас БРИДЖ!!! Который абсолютно не представляет куда ему транслировать запросы.
4. Возможно, выйти из этой ситуации Бриджом и можно, но поверьте, те что у Вас настройки на Бридж, они очень несущественны. Либо курите маны относительно настрояк софтверных Бриджей, либо используйте софтверный роутер.
5. Возможно прозвучит грубо, но вот выдавать 2м разным сетям одинаковую адресацию- это глупость ещё та.

rm_ · Сообщение **rm_** » 05.11.2009 10:32

И так господа, посидел немножко, посоветовался со спецами и вот к чему пришли:
1. Конфиг сервера (щем вот эту строчку) "Client-to-client" я по моему писал Вы про соедениене "точка-точка"- перечетайти ещё раз тип соединение, где о какой локальной сети идёт речь?? У Вас настройки на соелдинение только двух железяк.
2. Используйте любой софтверный маршрутизатор, бриджем Вам не выползти, поясняю почему: Бриндж - устройство работающее по интерфейсам (мак адресам) как он у Вас по Вашему будет маршрутизировать пакеты из 2х сетей, что бы Вы могли получить доступ к локалке???
3. "192.168.8.20 и 192.168.8.65 пингуют друг друга без проблем. 192.168.8.20 пингует любые хосты, 192.168.8.65 ничего не может пропинговать."- ну естественно, когда Вы пытаетесь пинговать с адреса 192.168.8.65 у Вас всё обрывается на адресе 192.168.8.20 (далее этого адреса маршруты неизвестны) потому что у Вас БРИДЖ!!! Который абсолютно не представляет куда ему транслировать запросы.
4. Возможно, выйти из этой ситуации Бриджом и можно, но поверьте, те что у Вас настройки на Бридж, они очень несущественны. Либо курите маны относительно настрояк софтверных Бриджей, либо используйте софтверный роутер.
5. Возможно прозвучит грубо, но вот выдавать 2м разным сетям одинаковую адресацию- это глупость ещё та.

Полнейший бред, от первой и до последней буквы. Вы со "спецами" так и не поняли, как в GNU/Linux работает программный мост между сетевыми интерфейсами.

step_slim · Сообщение **step_slim** » 05.11.2009 12:00

rm_ писал(а): ↑
05.11.2009 10:32
И так господа, посидел немножко, посоветовался со спецами и вот к чему пришли:
1. Конфиг сервера (щем вот эту строчку) "Client-to-client" я по моему писал Вы про соедениене "точка-точка"- перечетайти ещё раз тип соединение, где о какой локальной сети идёт речь?? У Вас настройки на соелдинение только двух железяк.
2. Используйте любой софтверный маршрутизатор, бриджем Вам не выползти, поясняю почему: Бриндж - устройство работающее по интерфейсам (мак адресам) как он у Вас по Вашему будет маршрутизировать пакеты из 2х сетей, что бы Вы могли получить доступ к локалке???
3. "192.168.8.20 и 192.168.8.65 пингуют друг друга без проблем. 192.168.8.20 пингует любые хосты, 192.168.8.65 ничего не может пропинговать."- ну естественно, когда Вы пытаетесь пинговать с адреса 192.168.8.65 у Вас всё обрывается на адресе 192.168.8.20 (далее этого адреса маршруты неизвестны) потому что у Вас БРИДЖ!!! Который абсолютно не представляет куда ему транслировать запросы.
4. Возможно, выйти из этой ситуации Бриджом и можно, но поверьте, те что у Вас настройки на Бридж, они очень несущественны. Либо курите маны относительно настрояк софтверных Бриджей, либо используйте софтверный роутер.
5. Возможно прозвучит грубо, но вот выдавать 2м разным сетям одинаковую адресацию- это глупость ещё та.

Полнейший бред, от первой и до последней буквы. Вы со "спецами" так и не поняли, как в GNU/Linux работает программный мост между сетевыми интерфейсами.

А что у нас специфика работы сети на каждом устройстве разная??? Тогда зачем были изобретены и приняты стандарты сетей ISO, если по Вашим словам на GNU/Linux работает всё по иному??? Это Вы сейчас полный бред сморозили. Возможно про программный мост я и не понял, но его работа не особо отличается от нормального моста, ведь не зря же его так назвали?- это раз. А то что у человека не, создавшего тему, не идут пинги с адреса 192.168.8.65 это как рас факт кривой работы этого моста, невозможность его трансляции адресов из-за отсутствие путей!
з.ы. Почитайте будет очень занимательно: http://www.gpntb.ru/win/book/5/Doc11.HTML

rm_ · Сообщение **rm_** » 05.11.2009 12:12

Возможно про программный мост я и не понял, но его работа не особо отличается от нормального моста, ведь не зря же его так назвали?- это раз. А то что у человека не, создавшего тему, не идут пинги с адреса 192.168.8.65 это как рас факт кривой работы этого моста, невозможность его трансляции адресов из-за отсутствие путей!

Даю подсказку: мост из двух интерфейсов, поднятый средствами brctl, по принципу работы ближе всего к самому обычному железячному Ethernet-свитчу. Какие маршруты, какие трансляции адресов, о чём речь вообще.

VZhiK84 · Сообщение **VZhiK84** » 05.11.2009 13:05

Есть одно подозрение:

Код: Выделить всё

vpn:~ # ifconfig -a
br0       Link encap:Ethernet  HWaddr 00:0C:29:A5:71:8A
          inet addr:192.168.8.20  Bcast:192.168.8.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:80 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:8002 (7.8 Kb)  TX bytes:42 (42.0 b)

eth0      Link encap:Ethernet  HWaddr 00:0C:29:A5:71:8A
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:591408 errors:0 dropped:0 overruns:0 frame:0
          TX packets:22003 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:50045499 (47.7 Mb)  TX bytes:15626244 (14.9 Mb)

eth1      Link encap:Ethernet  HWaddr 00:0C:29:A5:71:94
          inet addr:2.2.2.2  Bcast:2.2.2.2.127  Mask:255.255.255.224
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:47418 errors:0 dropped:0 overruns:0 frame:0
          TX packets:27658 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:19089817 (18.2 Mb)  TX bytes:6745970 (6.4 Mb)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:772 (772.0 b)  TX bytes:772 (772.0 b)

tap0      Link encap:Ethernet  HWaddr 5E:76:B9:52:32:BF
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:10 errors:0 dropped:0 overruns:0 frame:0
          TX packets:63 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:3188 (3.1 Kb)  TX bytes:5500 (5.3 Kb)

vpn:~ # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
2.2.2.2     0.0.0.0         255.255.255.224 U     0      0        0 eth1
192.168.8.0     0.0.0.0         255.255.255.0   U     0      0        0 br0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         <шлюз сервера>     0.0.0.0         UG    0      0        0 eth1

Так вот, в таблице маршрутизации не участвует интерфейс tap0. На клиенте он есть:

Код: Выделить всё

vzhikbook:/home/vzhik # route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.8.0     0.0.0.0         255.255.255.0   U     0      0        0 tap0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
172.16.0.0      0.0.0.0         255.255.0.0     U     0      0        0 eth0
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         172.16.253.1    0.0.0.0         UG    0      0        0 eth0

Хотя, с другой стороны, br0 объединяет tap0 и eth0....

step_slim · Сообщение **step_slim** » 05.11.2009 15:39

rm_ писал(а): ↑
05.11.2009 12:12
Возможно про программный мост я и не понял, но его работа не особо отличается от нормального моста, ведь не зря же его так назвали?- это раз. А то что у человека не, создавшего тему, не идут пинги с адреса 192.168.8.65 это как рас факт кривой работы этого моста, невозможность его трансляции адресов из-за отсутствие путей!

Даю подсказку: мост из двух интерфейсов, поднятый средствами brctl, по принципу работы ближе всего к самому обычному железячному Ethernet-свитчу. Какие маршруты, какие трансляции адресов, о чём речь вообще.

Вооот, воот Вы сами и ответили подвели к теме... "Ethernet-свитч" оборудование какого уровня??? На каком уровне модели OSI оно работает??? Верно на физическом, так о каком доступе к локалке может идти речь при VPN? Если идёт обращение только к ПОРТУ, а этот ПОРТ не знает никаких маршрутов в локалке? Разберём наглядно: 192.168.8.20 и 192.168.8.65 - это VPN соединение (пинги гоняются без проблем), где 192.168.8.20 злосчастный БРИДЖ, который на своём интерфейсе акромя 192.168.8.65(который кстати настроен в режим роутинга, если верить конфигам) ничего не видит и при попытки пинговать сеть 192.168.8.20 будет получать пакеты и не зная куда их переадресовывать, тупо сбрасывать, потому что он БРИДЖ, который только готов на себя получать пакеты, но не как не транслировать их в окружающую сеть. Повторюсь, тут выход, либо крутить настройки БРИДЖА до посинения, либо использовать програмный маршрутизатор.

rm_ · Сообщение **rm_** » 05.11.2009 16:30

он БРИДЖ, который только готов на себя получать пакеты, но не как не транслировать их в окружающую сеть

Мост потому так и называется, что транспортирует пакеты между своими интерфейсами ("портами").
Рекомендую почитать документацию по brctl, вот например: http://www.linuxfoundation.org/en/Net:Bridge

step_slim · Сообщение **step_slim** » 05.11.2009 17:29

rm_ писал(а): ↑
05.11.2009 16:30
он БРИДЖ, который только готов на себя получать пакеты, но не как не транслировать их в окружающую сеть

Мост потому так и называется, что транспортирует пакеты между своими интерфейсами ("портами").
Рекомендую почитать документацию по brctl, вот например: http://www.linuxfoundation.org/en/Net:Bridge

Алилуя

Я Вам это об этом и глаголю, что БРИДЖ работает только между интерфейсами, на физическом уровне, но не как на логическом. Что бы получить доступ к локалке БРИДЖ не подходит. Вы сами подумайте как он будет перенаправлять пакеты, если он работает только с интерфейсом. И на том интерфейсе поднят VPN. Как написано в конфиге: "Client-to-client" иными словами "точка-точка" всё за пределы точек он не выйдет. По поводу ссылки, отнюдь, ничего для себя нового не открыл, стандартное устройство 2го уровня.
з.ы. Вы мне лучше объясните почему создатель темы, ни вкаую не хочет использовать нормальную маршрутизацию на своём сервере? На клиенте значит поднят роутинг, а на сервере Бриджом выпутаться хочет.

VZhiK84 · Сообщение **VZhiK84** » 06.11.2009 04:15

Код: Выделить всё

з.ы. Вы мне лучше объясните почему создатель темы, ни вкаую не хочет использовать нормальную маршрутизацию на своём сервере? На клиенте значит поднят роутинг, а на сервере Бриджом выпутаться хочет.

Из-за специфического ПО, которому окромя обычных пакетов нужно получать и широковещательные (ПО писал не я, поэтому на вопрос "нахрена такой транспорт?" ответить не могу).

VZhiK84 · Сообщение **VZhiK84** » 08.11.2009 10:35

Перешел на маршрутизацию (пришлось делать костыли для работы широковещательных пакетов).
Есть только одна проблема: после того, как запущен опенвпн необходимо перезапускать SuSEfirewall, пока не перезапустишь - соединение устанавливается, но ничего (даже сервер) не пингуется. Интерфейс tun0 добавлен в список внутренних интерфейсов. Как лечить?

Newborn · Сообщение **Newborn** » 09.01.2011 17:42

unixforum.org

OpenVPN в режиме bridge (клиент видит сервер, но не видит сеть за ним)

OpenVPN в режиме bridge

Re: OpenVPN в режиме bridge

Re: OpenVPN в режиме bridge

Re: OpenVPN в режиме bridge

Re: OpenVPN в режиме bridge

Re: OpenVPN в режиме bridge

Re: OpenVPN в режиме bridge

Re: OpenVPN в режиме bridge

Re: OpenVPN в режиме bridge

Re: OpenVPN в режиме bridge

Re: OpenVPN в режиме bridge

Re: OpenVPN в режиме bridge

Re: OpenVPN в режиме bridge

Re: OpenVPN в режиме bridge

Re: OpenVPN в режиме bridge

Re: OpenVPN в режиме bridge

Re: OpenVPN в режиме bridge

Re: OpenVPN в режиме bridge

Re: OpenVPN в режиме bridge

Re: OpenVPN в режиме bridge

Re: OpenVPN в режиме bridge

Re: OpenVPN в режиме bridge

Re: OpenVPN в режиме bridge