Есть небольшая проблемка , есть варианты её обхода, но хочется разобраться.Есть Opensuse 11.4 2.6.37.1-1.2
У неё 2 интерфейса в 2 подсетяхeth0 inet addr:192.168.0.2 Bcast:192.168.0.255 Mask:255.255.255.0
eth1 inet addr:10.15.178.25 Bcast:10.15.178.255 Mask:255.255.255.0#netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
10.15.178.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
192.168.0.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 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 192.168.0.33 0.0.0.0 UG 0 0 0 eth0Есть 3-я сеть 10.15.161.0/24 (тут я и часть клиентов).
Все сети маршрутизируемы на сетевом оборудовании, т.е. мне от себя доступна сеть и 192.168.0.0/24 и 10.15.178.0/24.
НО! Сервер не доступен по ip 10.15.78.25 с других подсетей.
C клиентской сети ping 192.168.0.2 - проходит
И отсюда же ping 10.15.178.25 - не проходитВижу что проблема на сервере , так как на eth1 мой icmp приходит
#tcpdump -i eth1 'icmp'
listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
14:12:11.427596 IP 10.15.161.182 > 10.15.178.25: ICMP echo request....Тут же он должен уйти назад мне через eth0 default gw 192.168.0.33
#tcpdump -i eth0 'icmp'
Но тут пусто.А тут должны уходить IP 10.15.178.25 > 10.15.161.182 : ICMP echo reply.
Собственно вот,
Пробовал включать форвардинг
echo 1 > /proc/sys/net/ipv4/ip_forward
- не помагает .Есть у кого какие мысли?
> Есть у кого какие мысли?А еще есть такая штука, файрволл называется. В линуксе - iptables.
> А еще есть такая штука, файрволл называется. В линуксе - iptables.В Фаейрволе ниодного правила , Политики Accept
#iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destinationChain FORWARD (policy ACCEPT)
target prot opt source destinationChain OUTPUT (policy ACCEPT)
target prot opt source destination
> Есть у кого какие мысли?А еще есть
net.ipv4.conf.IFACE.rp_filter, которое может влиять при значении 1
> А еще есть
> net.ipv4.conf.IFACE.rp_filter, которое может влиять при значении 1# sysctl -a | grep net.ipv4.conf.lo.rp_filter
net.ipv4.conf.lo.rp_filter = 0
# sysctl -a | grep net.ipv4.conf.eth1.rp_filter
net.ipv4.conf.eth1.rp_filter = 0
# sysctl -a | grep net.ipv4.conf.eth0.rp_filter
net.ipv4.conf.eth0.rp_filter = 0
А что говорит?# ping -I eth0 10.15.161.182
> А что говорит?
> # ping -I eth0 10.15.161.182#ping -I eth1 10.15.161.182
PING 10.15.161.182 (10.15.161.182) from 192.168.0.2 eth1: 56(84) bytes of data.
^C
--- 10.15.161.182 ping statistics ---
32 packets transmitted, 0 received, 100% packet loss, time 31011ms
и
#ping -I eth0 10.15.161.182
PING 10.15.161.182 (10.15.161.182) from 192.168.0.2 eth0: 56(84) bytes of data.
64 bytes from 10.15.161.182: icmp_req=1 ttl=127 time=0.914 ms
Тут всё пошло
Не перекидывается пакет с одного интерфейса на другой.
Не могу только понять почему.
на сервере:
ip route get ip-с-которого-пингуем
что выдаёт и ещё роутинг тейбл с клиента.
> на сервере:
> ip route get ip-с-которого-пингуем
> что выдаёт и ещё роутинг тейбл с клиента.# ip route get 10.15.161.182
10.15.161.182 via 192.168.0.33 dev eth0 src 192.168.0.2
cache mtu 1500 advmss 1460 hoplimit 64
Т.е. я вижу что сервак шарит где находится клиент но отправить
ping -I eth1 10.15.161.182 не может - не перекидывает на default gwКлиент - винда
#route print
===========================================================================
Активные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
0.0.0.0 0.0.0.0 10.15.161.33 10.15.161.182 20
10.15.161.0 255.255.255.0 10.15.161.182 10.15.161.182 20
10.15.161.182 255.255.255.255 127.0.0.1 127.0.0.1 20
10.255.255.255 255.255.255.255 10.15.161.182 10.15.161.182 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
224.0.0.0 240.0.0.0 10.15.161.182 10.15.161.182 20
255.255.255.255 255.255.255.255 10.15.161.182 10.15.161.182 1
Основной шлюз: 10.15.161.33
===========================================================================
С виндового клиента сделайте # tracert 10.15.178.25
куда сеть 10.15.178.0/24 смотрит? в смысле с сетью 10.15.161.0/24 связан чем-нибудь?
а также надо на сервере сделать # traceroute 10.15.161.182
> С виндового клиента сделайте # tracert 10.15.178.25
> куда сеть 10.15.178.0/24 смотрит? в смысле с сетью 10.15.161.0/24 связан чем-нибудь?
> а также надо на сервере сделать # traceroute 10.15.161.182C:\Program Files\Support Tools>tracert 10.15.178.25
Трассировка маршрута к 10.15.178.25 с максимальным числом прыжков 30
1 <1 мс <1 мс <1 мс 10.15.161.33
2 * ^CТрасерт с клиента уходит на шлюз в этой сети и icmp запрос приходит на сервер!
09:34:16.282285 IP 10.15.161.182 > 10.15.178.25: ICMP echo request, id 512, seq 5139, length 40
Но не уходит назад через другой eth0 default gw 192.168.0.33Сети связаны на сетевом оборудовании , доступны через гетвэи. Аксесс листов нет.
Косяк на сервере . Воткнул такой же сервер, только OpenSuse 11.1, в те же сети , сделал такую же таблицу маршрутизации.- Всё пингуется как надо , по обоим интерфейсам.
> Косяк на сервере . Воткнул такой же сервер, только OpenSuse 11.1, в
> те же сети , сделал такую же таблицу маршрутизации.- Всё пингуется
> как надо , по обоим интерфейсам.ip ru sh
+
ip ro sh table main
ip ro sh table default
и все прочие table, которые есть в "ip ru sh" lookup-ах
>> Косяк на сервере . Воткнул такой же сервер, только OpenSuse 11.1, в
>> те же сети , сделал такую же таблицу маршрутизации.- Всё пингуется
>> как надо , по обоим интерфейсам.
> ip ru sh
> +
> ip ro sh table main
> ip ro sh table default
> и все прочие table, которые есть в "ip ru sh" lookup-ах# ip ru sh
0: from all lookup local
32766: from all lookup main
32767: from all lookup default# ip ro sh table local
broadcast 192.168.0.255 dev eth0 proto kernel scope link src 192.168.0.2
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
broadcast 10.15.178.255 dev eth1 proto kernel scope link src 10.15.178.25
local 10.15.178.25 dev eth1 proto kernel scope host src 10.15.178.25
broadcast 192.168.0.0 dev eth0 proto kernel scope link src 192.168.0.2
local 192.168.0.2 dev eth0 proto kernel scope host src 192.168.0.2
broadcast 10.15.178.0 dev eth1 proto kernel scope link src 10.15.178.25
local 127.0.0.2 dev lo proto kernel scope host src 127.0.0.1
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
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# ip ro sh table main
10.15.178.0/24 dev eth1 proto kernel scope link src 10.15.178.25
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.2
169.254.0.0/16 dev eth0 scope link
127.0.0.0/8 dev lo scope link
default via 192.168.0.33 dev eth0# ip ro sh table default
#
И ещё оговорюсь , это сервер виртуальный на VMWare server 2.0.2. Может отсюда ноги ростут ?
> И ещё оговорюсь , это сервер виртуальный на VMWare server 2.0.2. Может
> отсюда ноги ростут ?нет, это не из-за VMWare.
Надо что-то в iproute2 покрутить, чтобы ответы шли не через тот интерфейс, с которого пришли, а через default gateway.
> Надо что-то в iproute2 покрутить, чтобы ответы шли не через тот интерфейс,
> с которого пришли, а через default gateway.по дефолту оно так и работает, пока не настроишь pbr
- вот что я нарыл. Открываю 2 терминала
на одном
#ping -I eth1 10.15.161.182
PING 10.15.161.182 (10.105.160.182) from 192.168.0.2 eth1: 56(84) bytes of data .
^C
--- 10.15.161.182 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4006msна втором запущен
# tcpdump -i any 'icmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
14:16:32.138917 IP 10.15.178.25 > 10.15.161.182: ICMP echo request, id 2852, seq 147, length 64
14:16:32.139317 IP 10.15.161.182 > 10.15.178.25: ICMP echo reply, id 2852, seq 147, length 64
14:16:33.138990 IP 10.15.178.25 > 10.15.161.182: ICMP echo request, id 2852, seq 148, length 64
14:16:33.139474 IP 10.15.161.182 > 10.15.178.25: ICMP echo reply, id 2852, seq 148, length 64
14:16:34.139176 IP 10.15.178.25 > 10.15.161.182: ICMP echo request, id 2852, seq 149, length 64
14:16:34.139621 IP 10.15.161.182 > 10.15.178.25: ICMP echo reply, id 2852, seq 149, length 64
Пакеты и уходят и назад возвращаются на сервер, но не передаются на тот интерфейс от куда запущен ping.
ip route get 10.15.178.25 from 10.15.161.182 iif eth1
что даёт?какие-то правила iptables есть? особенно в таблице nat (-t nat)?
> ip route get 10.15.178.25 from 10.15.161.182 iif eth1
> что даёт?только наверно наоборот
# ip route get 10.15.161.182 from 10.15.178.25 iif eth1
RTNETLINK answers: No route to host
> какие-то правила iptables есть? особенно в таблице nat (-t nat)?нет , iptables пуст , политики Accept
а локально-то, пинг на 10.15.178.25 работает-то?
> а локально-то, пинг на 10.15.178.25 работает-то?ещё интересно посмотреть tcpdump'ом на то как транзитный трафик ходит через этот рутер, с того же 10.15.161.182 куда-нибудь в 10.15.178.ХХ
>> а локально-то, пинг на 10.15.178.25 работает-то?
> ещё интересно посмотреть tcpdump'ом на то как транзитный трафик ходит через этот
> рутер, с того же 10.15.161.182 куда-нибудь в 10.15.178.ХХда локально пинг на 10.15.178.25 идёт
При ping 10.15.178.25 c клиента icmp запросы доходят до сервера на этот интерфейс eth1, дальше с с eth0(так как там default gw) должны уйти icmp reply . Но c eth0 ничего не уходит.
Проблема не в сети , а в связке eth0-eth1. Я сам в шоке )) Грешу на VMware.
а если net.ipv4.conf.all.log_martians включить? в логах что-нибудь появится, и вообще в логах что-то есть?
> а если net.ipv4.conf.all.log_martians включить? в логах что-нибудь появится, и вообще
> в логах что-то есть?Проблема решилась так
echo 0 > /proc/sys/net/ipv4/conf/all/rp_filterОб этом писал PavelR
Извиняюсь что не совсем внимательно проверил.Только всё равно осталась доля непонятного.
Вот OpenSuse 11.1
## sysctl -a | grep rp_filter
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.arp_filter = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.default.arp_filter = 0
net.ipv4.conf.lo.rp_filter = 0
net.ipv4.conf.lo.arp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.eth0.arp_filter = 0
net.ipv4.conf.eth1.rp_filter = 0
net.ipv4.conf.eth1.arp_filter = 0Вот OpenSuse 11.4
# sysctl -a | grep rp_filter
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.arp_filter = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.default.arp_filter = 0
net.ipv4.conf.lo.rp_filter = 0
net.ipv4.conf.lo.arp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.eth0.arp_filter = 0
net.ipv4.conf.eth1.rp_filter = 0
net.ipv4.conf.eth1.arp_filter = 0Один в один. Только на 11.1 по дефолту такой баги нет.
Где то глубже ещё этот rp_filter что то фильтрует).
>[оверквотинг удален]
> Тут же он должен уйти назад мне через eth0 default gw
> 192.168.0.33
> #tcpdump -i eth0 'icmp'
> Но тут пусто.
> А тут должны уходить IP 10.15.178.25 > 10.15.161.182 : ICMP echo reply.
> Собственно вот,
> Пробовал включать форвардинг
> echo 1 > /proc/sys/net/ipv4/ip_forward
> - не помагает .
> Есть у кого какие мысли?- с сервака в ping в обе стороны. связь есть? значит проблема в транзите пакетов из одной сети в другую.
- cat /proc/sys/net/ipv4/ip_forward. изучаем
- iptables -t nat -L. изучаем
- смотрим, что для клиентов сетей маршруты в другую сеть настроены ч/з сервак (в сети 10 адреса 192 маршрутизируются на сервак и в сети 192 адреса 10 маршрутизируются на сервак).
- |как вариант, строим бридж на серваке