LINUX.ORG.RU
решено ФорумAdmin

OpenVPN bridge-mode не видно локальную сеть

 , , tap0


1

1

Добрый день всем.

Проблема настройки с openvpn-ом. Есть локальная сеть предприятия 192.168.1.0/24, компов около 100. Хотелось бы настроить впн через бридж для подключения пользователей в сеть. Всё это на дебиане. Конфиг сетевых интерфейсов на сервере cat /etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto br0
iface br0 inet static
  address 192.168.1.16
  netmask 255.255.255.0
  network 192.168.1.0
  broadcast 192.168.1.255
  gateway 192.168.1.1
  bridge_fd 0
  bridge-stp 0
  pre-up ifconfig eth0 down
  pre-up openvpn --mktun --dev tap0
  pre-up ifconfig tap0 down
  pre-up brctl addbr br0
  pre-up brctl addif br0 eth0
  pre-up brctl addif br0 tap0
  pre-up ifconfig eth0 0.0.0.0
  pre-up ifconfig tap0 0.0.0.0
  pre-up ifconfig eth0 up
  pre-up ifconfig tap0 up
  post-down ifconfig eth0 down
  post-down openvpn --rmtun --dev tap0
  post-down brctl delbr br0

После старта получаем # ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP qlen 1000
    link/ether 00:15:5d:01:03:0e brd ff:ff:ff:ff:ff:ff
3: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP qlen 100
    link/ether 5a:d7:84:51:72:21 brd ff:ff:ff:ff:ff:ff
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:15:5d:01:03:0e brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.16/24 brd 192.168.1.255 scope global br0
Конфиг vpn сервера: #cat /etc/openvpn/server-short.conf
port 1194

proto tcp
;proto udp

dev tap0
;dev tun

ca ca.crt
cert server.crt
key server.key  # This file should be kept secret
dh dh1024.pem

#ifconfig-pool-persist ipp.txt

server-bridge 192.168.1.16 255.255.255.0 192.168.1.30 192.168.1.39

#push "route 192.168.1.0 255.255.255.0 192.168.1.1"
push "comp-lzo 1"

client-config-dir ccd
client-to-client

keepalive 10 120
comp-lzo

persist-key
persist-tun

status openvpn-status.log
log         openvpn.log
verb 4

Конфиг клиента: $ cat /etc/openvpn/client1.ovpn.gkb.conf

client

dev tap
# dev tun
proto tcp
;proto udp
remote IP-сервера 1194

resolv-retry infinite

nobind

persist-key
persist-tun

ca ca-gkb.crt
cert client1-gkb.crt
key client1-gkb.key

ns-cert-type server

comp-lzo

# Set log file verbosity.
verb 4

log openvpn-gkb.log
status openvpn-status-gkb.log

После поднятия впн на клиенте получаем ip $ ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether bc:5f:f4:0c:27:0f brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.99/24 brd 192.168.0.255 scope global eth0
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether bc:5f:f4:0c:27:0d brd ff:ff:ff:ff:ff:ff
23: tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/ether fe:cc:ed:16:90:0d brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.30/24 brd 192.168.168.255 scope global tap0

Т.е. соединение получено и можно смело пинговать openvpn-сервер. $ ping 192.168.1.16

PING 192.168.1.16 (192.168.1.16) 56(84) bytes of data.
64 bytes from 192.168.1.16: icmp_req=1 ttl=64 time=57.6 ms
64 bytes from 192.168.1.16: icmp_req=2 ttl=64 time=54.5 ms
64 bytes from 192.168.1.16: icmp_req=3 ttl=64 time=7.09 ms
64 bytes from 192.168.1.16: icmp_req=4 ttl=64 time=12.7 ms
Одним словом на впн-сервер доступ имеем, а вот дальше в локальную сеть - никак. $ ping 192.168.1.3
PING 192.168.1.3 (192.168.1.3) 56(84) bytes of data.
From 192.168.1.30 icmp_seq=1 Destination Host Unreachable
From 192.168.1.30 icmp_seq=2 Destination Host Unreachable
From 192.168.1.30 icmp_seq=3 Destination Host Unreachable
From 192.168.1.30 icmp_seq=4 Destination Host Unreachable
From 192.168.1.30 icmp_seq=5 Destination Host Unreachable
From 192.168.1.30 icmp_seq=6 Destination Host Unreachable
^C
--- 192.168.1.3 ping statistics ---
7 packets transmitted, 0 received, +6 errors, 100% packet loss, time 6031ms
pipe 3
Что хотел добавить, кусок sysctl.conf на сервере:
net.ipv4.ip_forward=1
net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-filter-vlan-tagged = 0
net.bridge.bridge-nf-filter-pppoe-tagged = 0

iptables -S на сервере

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -i tap0 -j ACCEPT
-A INPUT -i br0 -j ACCEPT
-A FORWARD -i br0 -j ACCEPT

Подскажите, что я пропустил?

★★★

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

64 bytes from 192.168.1.16: icmp_req=1 ttl=64 time=57.6 ms
64 bytes from 192.168.1.16: icmp_req=2 ttl=64 time=54.5 ms
64 bytes from 192.168.1.16: icmp_req=3 ttl=64 time=7.09 ms
64 bytes from 192.168.1.16: icmp_req=4 ttl=64 time=12.7 ms

Так всегда или ты просто неудачный кусок вырезал? Не должно так скакать, тем более в локалке. Да еще попробуй другие компьютеры попинговать, может тот тебя просто выключен, или icmp reply отключен.

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

а на 192.168.1.3 вантуз со включенным брандмаузером?

Это к тому же AD и домен-сервер. Из локалки он виден, пингуется и даже рдп-ой можно ходить.

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

Так всегда или ты просто неудачный кусок вырезал? Не должно так скакать, тем более в локалке. Да еще попробуй другие компьютеры попинговать, может тот тебя просто выключен, или icmp reply отключен.

Это пинг от опенвпн-овского клиента (короче из дома стучусь на работу).

$ ping 192.168.1.16
PING 192.168.1.16 (192.168.1.16) 56(84) bytes of data.
64 bytes from 192.168.1.16: icmp_req=1 ttl=64 time=20.9 ms
64 bytes from 192.168.1.16: icmp_req=2 ttl=64 time=8.61 ms
64 bytes from 192.168.1.16: icmp_req=3 ttl=64 time=7.78 ms
64 bytes from 192.168.1.16: icmp_req=4 ttl=64 time=6.00 ms
64 bytes from 192.168.1.16: icmp_req=5 ttl=64 time=6.88 ms
64 bytes from 192.168.1.16: icmp_req=6 ttl=64 time=6.89 ms
64 bytes from 192.168.1.16: icmp_req=7 ttl=64 time=7.00 ms
64 bytes from 192.168.1.16: icmp_req=8 ttl=64 time=6.75 ms
64 bytes from 192.168.1.16: icmp_req=9 ttl=64 time=12.0 ms
64 bytes from 192.168.1.16: icmp_req=10 ttl=64 time=6.67 ms
64 bytes from 192.168.1.16: icmp_req=11 ttl=64 time=6.75 ms
64 bytes from 192.168.1.16: icmp_req=12 ttl=64 time=5.96 ms
64 bytes from 192.168.1.16: icmp_req=13 ttl=64 time=5.92 ms
64 bytes from 192.168.1.16: icmp_req=14 ttl=64 time=6.11 ms
64 bytes from 192.168.1.16: icmp_req=15 ttl=64 time=7.75 ms
64 bytes from 192.168.1.16: icmp_req=16 ttl=64 time=8.92 ms
64 bytes from 192.168.1.16: icmp_req=17 ttl=64 time=6.88 ms
64 bytes from 192.168.1.16: icmp_req=18 ttl=64 time=6.93 ms
64 bytes from 192.168.1.16: icmp_req=19 ttl=64 time=8.00 ms
64 bytes from 192.168.1.16: icmp_req=20 ttl=64 time=7.68 ms
64 bytes from 192.168.1.16: icmp_req=21 ttl=64 time=6.97 ms
64 bytes from 192.168.1.16: icmp_req=22 ttl=64 time=6.93 ms
^C
--- 192.168.1.16 ping statistics ---
22 packets transmitted, 22 received, 0% packet loss, time 21021ms
rtt min/avg/max/mdev = 5.927/7.931/20.908/3.116 ms

И пофигу какие компы пинговать - ничего не доступно кроме vpn-сервера. Ощущение, что на бридже пакеты не ходят. А как проверить этот бридж? Если скажем подключиться к openvpn-северу по ssh, то с него доступна вся локальная сеть. Схема сети получается где то вот такая.

[КлиентVPN-tap0(192.168.1.30)] --- (((провайдеры интернета))) --- [СерверVPN br0(tap0+eth0)192.168.1.16 ] — [Локалка 192.168.1.ХХХ]

В брижде загвоздка?

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

Нет. На Hyper-V того же 192.168.1.3 Win-2008R2

Для статистики сделал 3 раза

~$ traceroute 192.168.1.16 
traceroute to 192.168.1.16 (192.168.1.16), 30 hops max, 60 byte packets
 1  192.168.1.16 (192.168.1.16)  8.035 ms  54.269 ms  54.276 ms

~$ traceroute 192.168.1.16 
traceroute to 192.168.1.16 (192.168.1.16), 30 hops max, 60 byte packets
 1  192.168.1.16 (192.168.1.16)  7.917 ms  14.165 ms  14.173 ms

~$ traceroute 192.168.1.16 
traceroute to 192.168.1.16 (192.168.1.16), 30 hops max, 60 byte packets
 1  192.168.1.16 (192.168.1.16)  7.891 ms  14.197 ms  14.203 ms

И тоже на 192.168.1.3

~$ traceroute 192.168.1.3
traceroute to 192.168.1.3 (192.168.1.3), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * luna-mng.local (192.168.1.30)  2999.519 ms !H

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

Те же пирожки что и с vmware.

in the hyper-v manager, go to the settings for the vm you want to use a bridge on, and under every network interface that you want to use as part of the bridge enable the «allow mac address spoofing» checkbox.

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

Снимаю шляпу и благодарю! Всё заработало! Запинговалось, зашарилось и всё остальное!!! А ведь два дня бился головой об стенку ;-) Надо себе где то на заметку поставить про мак-спуффинг. Ещё раз, БОЛЬШОЕ спасибо!

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

Даже и представить себе не мог, что тут замешана HyperV и гуглил проблему по бриджу.

mango ★★★
() автор топика
27 марта 2015 г.
Ответ на: комментарий от anonymous_sama

Спасибо

Ух как оно. У практически один в один такая же ситуация. И искал так же решение, хорошо, что теперь оно здесь есть. Сей простой шаг ситуацию исправил. Теперь поправить только конфигурации файрволов на серверах сети и счастье вот оно, буду презентовать руководству и агитировать закрытие открытого наружу RDP.

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