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

Бродкасты через OpenVpn мост: движение в одну сторону??

 , ,


0

1

Привет! Прошу минуту помощи клуба :) Много перерыл на эту тему нету, даже нашел здесь ссылку на утилиту udp_broadcast_fw, но чувствую, что можно настроить прямо и правильно: Сервер: CentOs 6.3, OpenVPN 2.2 Клиент: WXP SP3, OpenVPN 2.2 Конфигурация openVPNа (сервер)

local 192.168.0.82
port 1723
proto udp
dev tap
ca ca.crt
cert server.crt
dh dh1024.pem
server-bridge 192.168.0.82 255.255.255.0 192.168.0.110 192.168.0.110
ifconfig-noexec
up /etc/openvpn/tap.open
route-up /etc/openvpn/route.bridge
client-to-client
duplicate-cn
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
log         /var/log/openvpn.log
verb 3

(клиент)

client
dev tap 
proto udp
remote ХХХ.ХХХ.ХХХ.ХХХ 1723
ca ca.crt
cert sklad.crt
key sklad.key
comp-lzo 
tls-auth ta.key 1

brctl на сервере

bridge name     bridge id               STP enabled     interfaces
br0             8000.00всякиебуквыещё       no              eth2
                                                                                   tap0

sysctl на сервере (избранное)

net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-arptables=0
net.ipv4.conf.br0.proxy_arp_pvlan=1
net.ipv4.conf.tap0.proxy_arp_pvlan=1
net.ipv4.conf.eth2.proxy_arp_pvlan=1
net.ipv4.conf.default.proxy_arp_pvlan=1
net.ipv4.conf.all.proxy_arp_pvlan=1
net.ipv4.conf.all.proxy_arp=1
net.ipv4.conf.default.proxy_arp=1
net.ipv4.conf.br0.proxy_arp=1
net.ipv4.conf.tap0.proxy_arp=1
net.ipv4.conf.eth2.proxy_arp=1

ip addr show (сервер)

2: eth2: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:1e:68:45:b7:c7 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::21e:68ff:fe45:b7c7/64 scope link
       valid_lft forever preferred_lft forever
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN
    link/ether 00:1e:68:45:b7:c7 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.82/24 brd 192.168.0.225 scope global br0
    inet6 fe80::21e:68ff:fe45:b7c7/64 scope link
       valid_lft forever preferred_lft forever
10: tap0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/ether 7a:28:aa:41:a5:d3 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::7828:aaff:fe41:a5d3/64 scope link
       valid_lft forever preferred_lft forever

ip route ls (сервер)

192.168.0.0/24 dev br0  proto kernel  scope link  src 192.168.0.82
default via 192.168.0.1 dev br0

ip route ls table local (сервер)

broadcast 192.168.0.255 dev br0  proto kernel  scope link  src 192.168.0.82
broadcast 127.255.255.255 dev lo  proto kernel  scope link  src 127.0.0.1
local 192.168.0.82 dev br0  proto kernel  scope host  src 192.168.0.82
broadcast 127.0.0.0 dev lo  proto kernel  scope link  src 127.0.0.1
broadcast 192.168.0.225 dev br0  proto kernel  scope link  src 192.168.0.82
local 127.0.0.1 dev lo  proto kernel  scope host  src 127.0.0.1
local 127.0.0.0/8 dev lo  proto kernel  scope host  src 127.0.0.1

Чтобы с клиента было возможно дойти до хостов за мостом приходится добавлять в таблицу routes

     192.168.0.76  255.255.255.255     192.168.0.82   192.168.0.110       1

из-за моста клиент доступен, винда находит клиентскую машину и влазит на неё легко (ресурсы расшарены), клиент же не может пробиться в сеть за мостом, бродкасты мрут в мосту, я их вижу tcpdump-ом на всех трех интерфейсах eth2, tap0 и br0, но уже за мостом wireshark показывает, что бродкастов в сети нет. Нужен доступ за мост от клиента, все бродкасты клиента должны гулять в сети.

на интерфейсе который в локальной сети офиса

tcpdump -envi eth2 ether dst ff:ff:ff:ff:ff:ff:

    192.168.0.110.netbios-ns > 192.168.0.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
16:57:14.487263 00:ff:a5:8d:0e:fe > Broadcast, ethertype IPv4 (0x0800), length 92: (tos 0x0, ttl 64, id 26574, offset 0, flags [none], proto UDP (17), length 78)
19 вот таких пакетов на один запрос сетевой шары по имени, но они не выпускаются в сеть, не форвардятся, они видимо остаются где-то на мосту.

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

Все оказалось веселей:

Паравиртуальные дрова от MS либо отсутствие галочки ARP spuffing в виртуальной машине. Ах, да! CentOS - виртуальная машина в среде Hyper V 2008 R2, тупанул, не сказал.... Значится ... когда добавил legacy netw адаптер и сказал, что спуффинг надо бы разрешить - все чудно заработало. стали ходить бкасты аж на 255.255.255.0 от клиента к серваку за мостом и обратно, когда я посмотрел вовнутрь пакета, увидел, что спуффинг на мосту не применялся - выходит, что паравиртуальные дрова написанные MS - фтопку.

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