LinuxForum.Fans
Тема

странный ip_forward (выборочный) (openvpn)

Автор: krpsh 36 сообщений 4247 просмотров
27.05.2014 13:35 · отредактировано #381494
"kisil" написал:
А вы перегрузите и клиент и сервер ВПН. Установите соединение и тогда смотрите.

пергрузил openvpn сервер - связь пропала (туннель не встает) какй-то затык iptables
разбираюсь
как разберусь покажу выводы
[console]
ip r
[/console]

"kisil" написал:
А вас не смущает что на ВПН - клиенте команда ip находит маршрут к 192,168,51,0/24 через 192.168.31.1 а должна через 192.168.150.1

согласен странно все это
таблица маршрутизации на openvpn клиенте есть в первом посте
привожу еще раз

text

#route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.160.2   192.168.150.1   255.255.255.255 UGH   15     0        0 tun3
192.168.150.1   0.0.0.0         255.255.255.255 UH    0      0        0 tun3
192.168.51.0    192.168.150.1   255.255.255.0   UG    20     0        0 tun3
192.168.31.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
0.0.0.0         192.168.31.1    0.0.0.0         UG    0      0        0 eth0
27.05.2014 13:51 #381498

ТС а также приведите команду
[console]ip a[/console]
с ВПН сервера-клиента.

27.05.2014 14:51 #381510

пришлось сменить ip у openvpn сервера теперь он 192,168,51,133 (был 192,168,51,132)

на openvpn сервере

text

# 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
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:72:0b:99 brd ff:ff:ff:ff:ff:ff
    inet 192.168.51.133/24 brd 192.168.51.255 scope global eth0
    inet6 fe80::5054:ff:fe72:b99/64 scope link 
       valid_lft forever preferred_lft forever
5: tun3: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/[65534] 
    inet 192.168.150.1 peer 192.168.150.2/32 scope global tun3
6: tun4: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/[65534] 
    inet 192.168.160.1 peer 192.168.160.2/32 scope global tun4

# ip r
192.168.160.2 dev tun4  proto kernel  scope link  src 192.168.160.1 
192.168.150.2 dev tun3  proto kernel  scope link  src 192.168.150.1 
192.168.51.0/24 dev eth0  proto kernel  scope link  src 192.168.51.133 
192.168.31.0/24 via 192.168.150.2 dev tun3  proto zebra  metric 20 
169.254.0.0/16 dev eth0  scope link  metric 1002 
default via 192.168.51.1 dev eth0

на openvpn клиенте

text

# 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
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:98:c3:50 brd ff:ff:ff:ff:ff:ff
    inet 192.168.31.37/24 brd 192.168.31.255 scope global eth0
    inet6 fe80::5054:ff:fe98:c350/64 scope link 
       valid_lft forever preferred_lft forever
3: tun3: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/[65534] 
    inet 192.168.150.2 peer 192.168.150.1/32 scope global tun3

# ip r
192.168.160.2 via 192.168.150.1 dev tun3  proto zebra  metric 3 
192.168.150.1 dev tun3  proto kernel  scope link  src 192.168.150.2 
192.168.51.0/24 via 192.168.150.1 dev tun3  proto zebra  metric 20 
192.168.31.0/24 dev eth0  proto kernel  scope link  src 192.168.31.37 
169.254.0.0/16 dev eth0  scope link  metric 1002 
default via 192.168.31.1 dev eth0
27.05.2014 14:56 #381512

после перезагрузки openvpn сервера вот как стало на openvpn клиенте

text

# ip ro get 192.168.51.6
192.168.51.6 via 192.168.150.1 dev tun3  src 192.168.150.2 
    cache  mtu 1500 advmss 1460 hoplimit 64
27.05.2014 15:05 · отредактировано #381514

Я точно не уверен, но могу предложыть вам прописать, временно, маршруты на ВПН сервере-клиенте в подсеть в которой они находятса при установке соединения 192.168.150.0/24
На сервере

text
route add -net 192.168.150.0 netmask 255.255.255.0 dev tun3

На клиенте

text
route add -net 192.168.150.0 netmask 255.255.255.0 dev tun3

Попробуйте может в этом загвоздка

27.05.2014 15:06 #381515
krpsh написал:
после перезагрузки openvpn сервера вот как стало на openvpn клиенте
text

# ip ro get 192.168.51.6
192.168.51.6 via 192.168.150.1 dev tun3  src 192.168.150.2 
    cache  mtu 1500 advmss 1460 hoplimit 64

О теперь совмем другое дело. А пинги идут?

27.05.2014 15:23 · отредактировано #381517
"kisil" написал:
Я точно не уверен, но могу предложыть вам прописать, временно, маршруты на ВПН сервере-клиенте в подсеть в которой они находятса при установке соединения 192.168.150.0/24
На сервере

route add -net 192.168.150.0 netmask 255.255.255.0 dev tun3

На клиенте

route add -net 192.168.150.0 netmask 255.255.255.0 dev tun3

Попробуйте может в этом загвоздка

спасибо за совет. я это уже пробовал вчера :-)
и сейчас еще раз попробовал - не помогает
если хотябы один пинг пришел с хоста из сети 192,168,51,0/24, то этот хост сразуже становится доступным с 192,168,31,1
причем даже после перезагрузки openvpn клиента и сервера
мистика....
в общем, пока решил остановить поиски (башка кругом за три дня разборов)
позже займусь
сейчас же, если надо сделать доступным хост из 192,168,51,0/24 просто пускаю пинг с него в сторону 192,168,31,1 и все работает
вот такой вот велосипед получился :-)

"kisil" написал:
О теперь совмем другое дело. А пинги идут?

идут

27.05.2014 15:27 #381518

не знаю важно это или нет
но маршруты до сетей за openvp сервером и клиентом прописывает quagga
очем и говорит вот эта строчка

text

192.168.31.0/24 via 192.168.150.2 dev tun3  proto zebra  metric 20

обратите внимание на слово ZEBRA

27.05.2014 15:42 #381519

То то я думаю что это за ЗЕБРА. ТС Пропишыте для проверки статические маршруты, без quagga

27.05.2014 15:50 #381520

прописал без quagga
тепреь на ВПН клиенте вот так

text

# ip r
192.168.150.1 dev tun3  proto kernel  scope link  src 192.168.150.2 
192.168.51.0/24 via 192.168.150.1 dev tun3 
192.168.31.0/24 dev eth0  proto kernel  scope link  src 192.168.31.37 
169.254.0.0/16 dev eth0  scope link  metric 1002 
default via 192.168.31.1 dev eth0

все осталось прежним :-(

27.05.2014 16:01 · отредактировано #381521

Ну я уже не знаю. Ждите подтянутса гуру сетевых вопросов что то подскажут
*CRAZY* *CRAZY* *CRAZY*
А traceroute как отрабатывает???? со стороны клиента и со стороны сервера???

27.05.2014 16:18 · отредактировано #381522

я же говорю мистика ...

traceroute отрабатывает как и должно быть

со стороны сервера

text

# traceroute 192.168.31.1
traceroute to 192.168.31.1 (192.168.31.1), 30 hops max, 60 byte packets
 1  192.168.51.1 (192.168.51.1)  0.851 ms  0.809 ms  0.787 ms
 2  192.168.51.133 (192.168.51.133)  2.618 ms  2.506 ms  2.459 ms
 3  192.168.150.2 (192.168.150.2)  112.415 ms  167.756 ms  167.566 ms
 4  192.168.31.1 (192.168.31.1)  167.511 ms  167.459 ms  167.408 ms

со стороны клиента

text

# traceroute 192.168.51.6
traceroute to 192.168.51.6 (192.168.51.6), 30 hops max, 38 byte packets
 1  192.168.31.37 (192.168.31.37)  3.874 ms  3.079 ms  1.551 ms
 2  192.168.150.1 (192.168.150.1)  55.152 ms  52.206 ms  53.561 ms
 3  192.168.51.6 (192.168.51.6)  52.623 ms  53.761 ms  52.263 ms

а вот со стороны клиента на хост, который не доступен (с которого еще не было пингов в сторону 192,168,31,1)

text

# traceroute 192.168.51.201
traceroute to 192.168.51.201 (192.168.51.201), 30 hops max, 38 byte packets
 1  *  *  *
 2  *  *  *
 3  *  *  *
 4  *  *  *
 5  *  *  *
 6  *^C
27.05.2014 16:23 #381523

А у вас Эта ваша Квага настроена на 192.168.51.1. Покажыте но щас маршруты с вашего 192.168.51.1

27.05.2014 16:32 #381525

квага настроена только на 192,168,51,133 (openvpn сервер) и 192,168,31,37 (openvpn клиент)
на 192,168,51,1 никакой кваги нет у него два провайдера и там мартшутизация настроена через iproute2 с разными таблицами и правилами

27.05.2014 16:39 #381526

Просто что то тут не то с маршрутами. Скорее всего это путаетса динамическая маршрутизацыя.
Вот вы пишыте вывод трейсерв со стороны сервера

"krpsh" написал:
1 192.168.51.1 (192.168.51.1) 0.851 ms 0.809 ms 0.787 ms

А вот со стороны клиента

"krpsh" написал:
1 192.168.31.37 (192.168.31.37) 3.874 ms 3.079 ms 1.551 ms

Просто со стороны сервера первое обращение на пути к сети 192.168.31.0 идёт на ваш шлюз в интернет, а потом с него уже на ВПН-сервер который и есть шлюзом в нужную сеть. А со стороны клиента такого нету. Получаетса просто что после удачного пинга для нового компа создаётса верный маршрут и потом пинги идут. Тока я никак не пойму где он создаётса. Вот такие мысли.

27.05.2014 22:21 · отредактировано #381586
kisil написал:
Просто что то тут не то с маршрутами. Скорее всего это путаетса динамическая маршрутизацыя.
Вот вы пишыте вывод трейсерв со стороны сервера
[quote="krpsh"]1 192.168.51.1 (192.168.51.1) 0.851 ms 0.809 ms 0.787 ms

А вот со стороны клиента

"krpsh" написал:
1 192.168.31.37 (192.168.31.37) 3.874 ms 3.079 ms 1.551 ms

Просто со стороны сервера первое обращение на пути к сети 192.168.31.0 идёт на ваш шлюз в интернет, а потом с него уже на ВПН-сервер который и есть шлюзом в нужную сеть. А со стороны клиента такого нету. Получаетса просто что после удачного пинга для нового компа создаётса верный маршрут и потом пинги идут. Тока я никак не пойму где он создаётса. Вот такие мысли.[/quote]

Просто вывод команды traceroute на стороне клиента сделана на шлюзе вот и нет шлюза 192,168,31,1

Динамическая маршрутизация скорее всего не причем (пока не уверен), т.к квага правильные маршруты добавляет
Суть проблемы в том (смотри первый пост, там все написано), что openvpn клиент не хочет пересылать пакеты с интерфейса eth0 в tun3
Хотя все маршруты на нем прописаны. И сам openvpn клиент отлично видит всю сеть 192,168,51,0/24, находящуюся за openvpn сервером.
Поэтому тема ветки так и называется "странный ip_forward".
Пока грешу на настройки маршрутизации ядра в Centos 6.5. (В ближайшее время планирую восполнить этот пробел в образовании, почитать литературку)

Войдите или зарегистрируйтесь, чтобы ответить.