LinuxForum.Fans
Тема

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

Автор: krpsh 36 сообщений 4248 просмотров
27.05.2014 10:03 · отредактировано #381462

Здравствуйте!
станную картину наблюдаю
ось Centos 6.5
настроил связь между двумя подсетями через openvpn

на компе (шлюзе, но это не важно на других компах та же ситуация) за openvpn клиентом пингую комп в сети за openvpn сервером

text

#ping 192.168.51.1
PING 192.168.51.1 (192.168.51.1): 56 data bytes
64 bytes from 192.168.51.1: seq=0 ttl=62 time=57.422 ms
64 bytes from 192.168.51.1: seq=1 ttl=62 time=55.904 ms
^C
--- 192.168.51.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 55.904/56.663/57.422 ms

ответы идут, все ок
в это время на openvpn клиенте

text

#tcpdump -ni tun3 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun3, link-type RAW (Raw IP), capture size 65535 bytes
09:44:39.197502 IP 192.168.31.1 > 192.168.51.1: ICMP echo request, id 50298, seq 0, length 64
09:44:39.252128 IP 192.168.51.1 > 192.168.31.1: ICMP echo reply, id 50298, seq 0, length 64
09:44:40.198208 IP 192.168.31.1 > 192.168.51.1: ICMP echo request, id 50298, seq 1, length 64
09:44:40.250893 IP 192.168.51.1 > 192.168.31.1: ICMP echo reply, id 50298, seq 1, length 64
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel

все ок пакетики ходят как надо

теперь пробую пингануть другой комп

text

#ping 192.168.51.6  
PING 192.168.51.6 (192.168.51.6): 56 data bytes
^C
--- 192.168.51.6 ping statistics ---
24 packets transmitted, 0 packets received, 100% packet loss

в ответ тишина
в это время на openvpn клиенте

text

#tcpdump -ni tun3 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun3, link-type RAW (Raw IP), capture size 65535 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel

# tcpdump -ni eth0 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
09:49:06.417367 IP 192.168.31.1 > 192.168.51.6: ICMP echo request, id 52346, seq 20, length 64
09:49:07.415450 IP 192.168.31.1 > 192.168.51.6: ICMP echo request, id 52346, seq 21, length 64
09:49:08.416001 IP 192.168.31.1 > 192.168.51.6: ICMP echo request, id 52346, seq 22, length 64
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel

т.е на eth0 пакеты есть, а на tun3 тишина
мистика...
почему же пинги на 192,168,51,1 перенаправляются c eth0 в tun3, а пинги на 192,168,51,6 не перенаправляются

ps:
естественно что на openvpn клиенте

text

#cat /proc/sys/net/ipv4/ip_forward 
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

iptables на openvpn клиенте

text

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         


Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
27.05.2014 10:18 #381464

Возможно что на 192.168.51.6 файрвол блокирует.

27.05.2014 10:19 · отредактировано #381465

как же он блокирует если пинги до него не доходять ?
ведь на tun3 пингов-то нет
ps:
с openvpn клиента

text

# ping 192.168.51.6
PING 192.168.51.6 (192.168.51.6) 56(84) bytes of data.
64 bytes from 192.168.51.6: icmp_seq=1 ttl=63 time=68.9 ms
64 bytes from 192.168.51.6: icmp_seq=2 ttl=63 time=57.7 ms
^C
--- 192.168.51.6 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1435ms
rtt min/avg/max/mdev = 57.737/63.350/68.964/5.619 ms
27.05.2014 10:20 #381466

Или на 192.168.51.1 и 192.168.51.6 разные сетевые настройки и таблицы маршрутов.

27.05.2014 10:21 #381468
kisil написал:
Или на 192.168.51.1 и 192.168.51.6 разные сетевые настройки и таблицы маршрутов.

Скорее на 192.168.51.6.

27.05.2014 10:22 #381470
krpsh написал:
как же он блокирует если пинги до него не доходять

Отправляются на него

text
9:49:06.417367 IP 192.168.31.1 > 192.168.51.6:
27.05.2014 10:22 #381471
"Kettler" написал:
Скорее на 192.168.51.6.

Да. Я об этом. Или на 192.168.51.6 дефолтный шлюз другой или нету маршрута в нужную сеть

27.05.2014 10:24 #381472
kisil написал:
[quote="Kettler"]Скорее на 192.168.51.6.

Да. Я об этом. Или на 192.168.51.6 дефолтный шлюз другой или нету маршрута в нужную сеть[/quote]
Согласен полностью.

27.05.2014 10:24 · отредактировано #381473
Kettler написал:
[quote=krpsh]как же он блокирует если пинги до него не доходять

Отправляются на него

text
9:49:06.417367 IP 192.168.31.1 > 192.168.51.6:

[/quote]

Но не возращаютса. Проблема 192.168.51.6 с маршрутом в сеть 192.168.31.0/24

27.05.2014 10:28 · отредактировано #381474

может я чего не понимаю
но как может 192,168,51,6 ответить на пинги, которые до него не ДОХОДЯТ
ведь в момент пингов 192,168,51,6 на tun3 ТИШИНА
пинги есть ТОЛЬКО на eth0

27.05.2014 10:32 #381475
kisil написал:
[quote=Kettler][quote=krpsh]как же он блокирует если пинги до него не доходять

Отправляются на него

text
9:49:06.417367 IP 192.168.31.1 > 192.168.51.6:

[/quote]

Но не возращаютса. Проблема 192.168.51.6 с маршрутом в сеть 192.168.31.0/24[/quote]


эту строчку Вы выхватили с eth0
я бы понял Вас если бы это было на tun3

27.05.2014 10:33 #381476

ТС нарисуйте схиматически вашу сеть. Тока тот участок который вы описываете.
1. Вы пробуете пинговать 192.168.51.6 с какой сети???
2. 192.168.51.1 это есть ВПН-клиент и он же шлюз между сетями 192.168.51.0/24 и 192.168.31.0/24
3. Покажыте сетевые настройки и таблицу маршрутов с 192.168.51.6

27.05.2014 10:58 · отредактировано #381479

схема

br -lan 192.168.31.1 |gw| eth1 -------------internet-------------------------------------- eth1 |gw| eth0 192.168.51.1
| |------------------------------------------------
| | |
eth0 192.168.31.37 |openvpn client| tun3 192.168.150.2 ----------- tun3 192.168.150.1 |openvpn srv| eth0 192.168.51.132 eth1 192.168.51.6


1) пинги на 192,168,51,6 я посылаю с 192,168,31,1
кстати, с 192,168,31,37 пинги на 192,168,51,6 идут без проблем
2) нет, на схеме все видно
3) это тут причем, я же говорю, что пинги до него НЕ ДОХОДЯТ
вот

text

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.51.1    0.0.0.0         UG    1      0        0 eth1
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
192.168.31.0    192.168.51.132  255.255.255.0   UG    0      0        0 eth1
192.168.51.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.150.0   192.168.51.132  255.255.255.0   UG    0      0        0 eth1

# ifconfig eth1
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.51.6  netmask 255.255.255.0  broadcast 192.168.51.255
        inet6 fe80::cabe:19ff:fe27:dcd3  prefixlen 64  scopeid 0x20<link>
        ether c8:be:19:27:dc:d3  txqueuelen 1000  (Ethernet)
        RX packets 3377252121  bytes 3467623684861 (3.1 TiB)
        RX errors 0  dropped 2397178  overruns 0  frame 0
        TX packets 2690683356  bytes 3568360421818 (3.2 TiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

еще раз как следует прочтите, пожалуйста, прервый пост
проблема в том что openvpn клиент (192,168,31,37) перенаправляет пакеты с eth0 в tun3 только для 192,168,51,1

27.05.2014 11:20 #381481

и чтобы окончательно Вас огорчить (или себя)
с 192,168,51,6 на 192,168,31,1 пинги идут
пингую с 192,168,51,6

text

ping 192.168.31.1
PING 192.168.31.1 (192.168.31.1) 56(84) bytes of data.
64 bytes from 192.168.31.1: icmp_seq=1 ttl=62 time=57.7 ms
64 bytes from 192.168.31.1: icmp_seq=2 ttl=62 time=62.3 ms
64 bytes from 192.168.31.1: icmp_seq=3 ttl=62 time=89.0 ms

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

27.05.2014 11:28 #381483
krpsh написал:
и чтобы окончательно Вас огорчить (или себя)
с 192,168,51,6 на 192,168,31,1 пинги идут
пингую с 192,168,51,6
text

ping 192.168.31.1
PING 192.168.31.1 (192.168.31.1) 56(84) bytes of data.
64 bytes from 192.168.31.1: icmp_seq=1 ttl=62 time=57.7 ms
64 bytes from 192.168.31.1: icmp_seq=2 ttl=62 time=62.3 ms
64 bytes from 192.168.31.1: icmp_seq=3 ttl=62 time=89.0 ms

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

При этих пингах прослушайте tcpdump трафик на вашых ВПН сервере-клиенте.
Такое впечетление что трафик ходит по разному

27.05.2014 11:43 · отредактировано #381484

ха!
нашлось, ура!!!!!! (три дня мытарств)
вот что значить коллективный разум
хотите прикол!!

если с 192,168,31,1 пинговать 192,168,51,6
то ответов нет

если хоть один раз пингануть с 192,168,51,6 в сторону 192,168,31,1
ответ придет
и только ПОСЛЕ ЭТОГО

можно свободно пингануть с 192,168,31,1 в сторону 192,168,51,6

проверял на других компам из сетки 192,168,51,0/24

надо все обдумать...

27.05.2014 12:04 #381485

ТС покажыте но на вашем ВПН-клиенте, щас когда идут пинги
[console]ip rule list
ip route get 192.168.56.6[/console]
И было бы хорошо опробывать послеюнюю команду когда пинги не идут

27.05.2014 12:53 · отредактировано #381487

на openvpn клиенте

text

# ip rule list
0:    from all lookup local 
32766:    from all lookup main 
32767:    from all lookup default 

# ip route get 192.168.56.6
192.168.56.6 via 192.168.31.1 dev eth0  src 192.168.31.37 
    cache  mtu 1500 advmss 1460 hoplimit 64

с openvpn клиента пинги идут свобоно на любой комп из 192,168,51,0/24

с 192,168,31,1 пинг на 192,168,51,4 не идет
на openvpn клиенте

text

# ip route get 192.168.56.4
192.168.56.4 via 192.168.31.1 dev eth0  src 192.168.31.37 
    cache  mtu 1500 advmss 1460 hoplimit 64

стоит мне с 192,168,51,4 пингануть в сторону 192,168,31,1
приходит один ответ
и тут же с 192,168,31,1 комп 192,168,51,4 становиться доступен


я начал думать, что на openvpn клиенте есть что-то, что хранит ip адреса из сетки 192,168,51,0/24
о как !!
решил перегрузить openvpn клиент
после перезагрузки, те что пинговались, так и пингуются, а новые компы из 192,168,51,0/24 так же не доступны
мистика...
может это баг в маршрутизации у Centos6.5 или же у нее какая нибудь настройка ядра не так выставлена для маршрутизации

27.05.2014 12:56 #381488

А вы перегрузите и клиент и сервер ВПН. Установите соединение и тогда смотрите.

27.05.2014 13:05 · отредактировано #381489

ТС вот тут не стиковка.
Вот что вы привели

"krpsh" написал:

# ip route get 192.168.56.6
192.168.56.6 via 192.168.31.1 dev eth0 src 192.168.31.37
cache mtu 1500 advmss 1460 hoplimit 64


# ip route get 192.168.56.4
192.168.56.4 via 192.168.31.1 dev eth0 src 192.168.31.37
cache mtu 1500 advmss 1460 hoplimit 64

А вас не смущает что на ВПН - клиенте команда ip находит маршрут к 192,168,51,0/24 через 192.168.31.1 а должна через 192.168.150.1
Интересно почему не идут пакеты на нужный маршрут
Покажыте но на ВПН-клиенте и сервере
[console]ip r[/console]

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