Не ходят пинги в локалке. Кто виноват и что делать???

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Не ходят пинги в локалке. Кто виноват и что делать???

Andrew A. Sabitov
Hi!
Коллеги, кто может раскрыть секрет: что, хотя бы в теории, может убивать
пакеты _до_ iptables???

Симптомы:

Есть раутер локальной сети, стоящий между юзерами и DMZ.
eth1 смотрит в DMZ, на eth0 взведена куча vlan'он, каждый из которых
смотрит
в нужный кусочек пользовательской сети. На раутере накручены
iptables+ipset.
Шейпер и ebtables не используются

В первом приближении (и с ОЧЕНЬ хорошей точностью) все работает. Но!!!
Совершенно случайно обнаружил проблему, возникновение которой объяснить
не могу уже неделю :(

В DMZ есть машина 172.16.0.11 (этот момент не принципиален, т.к. пробовал с
разных машин и даже из разных IP-сетей, как из DMZ, так и
пользовательских). С
этой машины пускается пинг на 2 адреса в одной из пользовательских сетей.
Для определенности, пусть это будут 172.17.18.19 и 172.17.18.40.

Получаем такой результат:
===============================================================
sabitov@fig ~ $ ping 172.17.18.19
PING 172.17.18.19 (172.17.18.19) 56(84) bytes of data.
^C
--- 172.17.18.19 ping statistics ---
6 packets transmitted, 0 received, 100% packet loss, time 5002ms

sabitov@fig ~ $ ping 172.17.18.40
PING 172.17.18.40 (172.17.18.40) 56(84) bytes of data.
64 bytes from 172.17.18.40: icmp_seq=1 ttl=63 time=5.59 ms
64 bytes from 172.17.18.40: icmp_seq=2 ttl=63 time=4.90 ms
^C
--- 172.17.18.40 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 4.900/5.247/5.594/0.347 ms
===============================================================

Перед пинганьем на раутере запускаем:
tcpdump -n -i eth0.0018 net 172.17.18.0/24 and host 172.16.0.11
tcpdump -n -i eth1          net 172.17.18.0/24 and host 172.16.0.11

На eth0.0018 имеем:
===============================================================
12:38:00.277614 IP 172.16.0.11 > 172.17.18.19: ICMP echo request, id
26647, seq 1, length 64
12:38:00.283405 IP 172.17.18.19 > 172.16.0.11: ICMP echo reply, id
26647, seq 1, length 64
12:38:01.280200 IP 172.16.0.11 > 172.17.18.19: ICMP echo request, id
26647, seq 2, length 64
12:38:01.285974 IP 172.17.18.19 > 172.16.0.11: ICMP echo reply, id
26647, seq 2, length 64
12:38:02.280152 IP 172.16.0.11 > 172.17.18.19: ICMP echo request, id
26647, seq 3, length 64
12:38:02.285944 IP 172.17.18.19 > 172.16.0.11: ICMP echo reply, id
26647, seq 3, length 64
12:38:03.280164 IP 172.16.0.11 > 172.17.18.19: ICMP echo request, id
26647, seq 4, length 64
12:38:03.285961 IP 172.17.18.19 > 172.16.0.11: ICMP echo reply, id
26647, seq 4, length 64
12:38:04.280186 IP 172.16.0.11 > 172.17.18.19: ICMP echo request, id
26647, seq 5, length 64
12:38:04.286543 IP 172.17.18.19 > 172.16.0.11: ICMP echo reply, id
26647, seq 5, length 64
12:38:05.280201 IP 172.16.0.11 > 172.17.18.19: ICMP echo request, id
26647, seq 6, length 64
12:38:05.286016 IP 172.17.18.19 > 172.16.0.11: ICMP echo reply, id
26647, seq 6, length 64
12:38:13.170502 IP 172.16.0.11 > 172.17.18.40: ICMP echo request, id
26648, seq 1, length 64
12:38:13.175813 IP 172.17.18.40 > 172.16.0.11: ICMP echo reply, id
26648, seq 1, length 64
12:38:14.172288 IP 172.16.0.11 > 172.17.18.40: ICMP echo request, id
26648, seq 2, length 64
12:38:14.176868 IP 172.17.18.40 > 172.16.0.11: ICMP echo reply, id
26648, seq 2, length 64
===============================================================

На eth1:
===============================================================
12:38:00.277575 IP 172.16.0.11 > 172.17.18.19: ICMP echo request, id
26647, seq 1, length 64
12:38:01.280166 IP 172.16.0.11 > 172.17.18.19: ICMP echo request, id
26647, seq 2, length 64
12:38:02.280124 IP 172.16.0.11 > 172.17.18.19: ICMP echo request, id
26647, seq 3, length 64
12:38:03.280132 IP 172.16.0.11 > 172.17.18.19: ICMP echo request, id
26647, seq 4, length 64
12:38:04.280154 IP 172.16.0.11 > 172.17.18.19: ICMP echo request, id
26647, seq 5, length 64
12:38:05.280164 IP 172.16.0.11 > 172.17.18.19: ICMP echo request, id
26647, seq 6, length 64
12:38:13.170466 IP 172.16.0.11 > 172.17.18.40: ICMP echo request, id
26648, seq 1, length 64
12:38:13.175902 IP 172.17.18.40 > 172.16.0.11: ICMP echo reply, id
26648, seq 1, length 64
12:38:14.172256 IP 172.16.0.11 > 172.17.18.40: ICMP echo request, id
26648, seq 2, length 64
12:38:14.176978 IP 172.17.18.40 > 172.16.0.11: ICMP echo reply, id
26648, seq 2, length 64
===============================================================

Видно, что с .40 все хорошо, а ответы от .19 не проходят через раутер.
Возникло подозрение,
что где-то в iptables я это блокирую, как результат напихал кучу правил
для логирования
прохождения пакета по цепочкам.

Это реальный кусок без купюр:
===============================================================
iptables -t raw    -A PREROUTING -s 172.17.18.0/24 -j LOG --log-prefix
"172.17.18.0 (raw): "
iptables -t mangle -A PREROUTING -s 172.17.18.0/24 -j LOG --log-prefix
"172.17.18.0 (mangle): "
#маркируем прямые обращения к squid-у для блокировки в цепочке INPUT
iptables -t mangle -A PREROUTING -p TCP -s 172.16.0.0/15 --dport 3128 -j
MARK --set-mark 3128

iptables -t nat -A PREROUTING -s 172.17.18.0/24 -j LOG --log-prefix
"172.17.18.0 (nat): "
iptables -t nat -A PREROUTING -p TCP \
         -s 172.16.0.0/15 \
         -m set ! --match-set "ip4_direct_http_clients" src \
         -m set ! --match-set "ip4_all_vlans"  dst \
         -m set   --match-set "ip4_proxying_port_list" dst \
                 -j REDIRECT --to-ports 3128


iptables -A FORWARD -s 172.17.18.0/24 -j LOG --log-prefix "172.17.18.0
(1): "
iptables -A FORWARD -p ALL -m set --match-set "ip4_black_list" src      
-j DROP
iptables -A FORWARD -s 172.17.18.0/24 -j LOG --log-prefix "172.17.18.0
(2): "

iptables -A FORWARD -p ALL ! -s 172.17.32.0/24   -m set --match-set
"ip4_all_vlans" src    -m set ! --match-set "mac" src,src -m limit
--limit 3/minute --limit-burst 3 -j LOG   --log-prefix "Wrong MAC-IP
pair (FORWARD): "
iptables -A FORWARD -p ALL ! -s 172.17.32.0/24   -m set --match-set
"ip4_all_vlans" src    -m set ! --match-set "mac" src,src -j DROP

iptables -A FORWARD -s 172.17.18.0/24 -j LOG --log-prefix "172.17.18.0
(3): "

iptables -A FORWARD -p ALL -m set --match-set "ip4_white_list_2_inet"
src -j ACCEPT
iptables -A FORWARD -p ALL -m set --match-set "ip4_white_list_2_inet"
dst -j ACCEPT

iptables -A FORWARD -p ALL -m addrtype --dst-type
BROADCAST               -j DROP

iptables -A FORWARD -s 172.17.18.0/24 -j LOG --log-prefix "172.17.18.0
(4): "

iptables -A FORWARD -p ALL  -m conntrack --ctstate
ESTABLISHED,RELATED    -j ACCEPT

iptables -A FORWARD -s 172.17.18.0/24 -j LOG --log-prefix "172.17.18.0
(5): "

iptables -A FORWARD -p TCP  -j forward_tcp_packets
iptables -A FORWARD -p UDP  -j forward_udp_packets
iptables -A FORWARD -p ICMP -j forward_icmp_packets

iptables -A FORWARD -s 172.17.18.0/24 -j LOG --log-prefix "172.17.18.0
(6): "

iptables -A forward_icmp_packets -s 172.17.18.0/24 -j LOG --log-prefix
"172.17.18.0: "
iptables -A forward_icmp_packets -p ICMP -j ACCEPT
===============================================================

Если верить диаграмме http://inai.de/images/nf-packet-flow.png , то у
меня должно в первую
очередь отработать логирование входящего пакета в цепочке PREROUTING
таблицы raw.
Дык вот, для ответов от .40 это так и есть, а для .19 -- тишина!
===============================================================
router ~ # grep 172.17.18. /var/log/messages | grep 172.16.0.11
Jun  4 12:38:13 router kernel: 172.17.18.0 (raw): IN=eth0.0018 OUT=
MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=100 PROTO=ICMP
TYPE=0 CODE=0 ID=26648 SEQ=1
Jun  4 12:38:13 router kernel: 172.17.18.0 (raw): IN=eth0.0018 OUT=
MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=100 PROTO=ICMP
TYPE=0 CODE=0 ID=26648 SEQ=1
Jun  4 12:38:13 router kernel: 172.17.18.0 (mangle): IN=eth0.0018 OUT=
MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=100 PROTO=ICMP
TYPE=0 CODE=0 ID=26648 SEQ=1
Jun  4 12:38:13 router kernel: 172.17.18.0 (1): IN=eth0.0018 OUT=eth1
MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=100 PROTO=ICMP
TYPE=0 CODE=0 ID=26648 SEQ=1
Jun  4 12:38:13 router kernel: 172.17.18.0 (2): IN=eth0.0018 OUT=eth1
MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=100 PROTO=ICMP
TYPE=0 CODE=0 ID=26648 SEQ=1
Jun  4 12:38:13 router kernel: 172.17.18.0 (3): IN=eth0.0018 OUT=eth1
MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=100 PROTO=ICMP
TYPE=0 CODE=0 ID=26648 SEQ=1
Jun  4 12:38:13 router kernel: 172.17.18.0 (4): IN=eth0.0018 OUT=eth1
MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=100 PROTO=ICMP
TYPE=0 CODE=0 ID=26648 SEQ=1
Jun  4 12:38:14 router kernel: 172.17.18.0 (raw): IN=eth0.0018 OUT=
MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=101 PROTO=ICMP
TYPE=0 CODE=0 ID=26648 SEQ=2
Jun  4 12:38:14 router kernel: 172.17.18.0 (raw): IN=eth0.0018 OUT=
MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=101 PROTO=ICMP
TYPE=0 CODE=0 ID=26648 SEQ=2
Jun  4 12:38:14 router kernel: 172.17.18.0 (mangle): IN=eth0.0018 OUT=
MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=101 PROTO=ICMP
TYPE=0 CODE=0 ID=26648 SEQ=2
Jun  4 12:38:14 router kernel: 172.17.18.0 (1): IN=eth0.0018 OUT=eth1
MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=101 PROTO=ICMP
TYPE=0 CODE=0 ID=26648 SEQ=2
Jun  4 12:38:14 router kernel: 172.17.18.0 (2): IN=eth0.0018 OUT=eth1
MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=101 PROTO=ICMP
TYPE=0 CODE=0 ID=26648 SEQ=2
Jun  4 12:38:14 router kernel: 172.17.18.0 (3): IN=eth0.0018 OUT=eth1
MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=101 PROTO=ICMP
TYPE=0 CODE=0 ID=26648 SEQ=2
Jun  4 12:38:14 router kernel: 172.17.18.0 (4): IN=eth0.0018 OUT=eth1
MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=101 PROTO=ICMP
TYPE=0 CODE=0 ID=26648 SEQ=2
===============================================================

Эта проблема касается не только пингов, а трафика "вообще". Например,
через раз срабатывает обход устройств по SNMP.



Reply | Threaded
Open this post in threaded view
|

Re: Не ходят пинги в локалке. Кто виноват и что делать???

Alex Efros-4
Hi!

On Thu, Jun 04, 2015 at 01:39:57PM +0600, Andrew A. Sabitov wrote:
> Коллеги, кто может раскрыть секрет: что, хотя бы в теории, может убивать
> пакеты _до_ iptables???

Ядро, разумеется. Там тоже есть фильтры пакетов, например проверки source
route работают в сложных конфигурациях… странновато. Я предпочитаю их
отключать и реализовывать защиту от спуфинга ручками в iptables.

При этом в hardened настройки ядра по умолчанию для source route
изменились недавно (https://bugs.gentoo.org/show_bug.cgi?id=534132),
поэтому я бы рекомендовал явно прописать в /etc/sysctl.conf:
    net.ipv4.conf.default.rp_filter = 0
    net.ipv4.conf.all.rp_filter = 0
и перегрузиться (или выставить этот 0 ручками в /proc или через sysctl для
всех интерфейсов плюс к default и all).

--
                        WBR, Alex.

Reply | Threaded
Open this post in threaded view
|

Re: Не ходят пинги в локалке. Кто виноват и что делать???

Andrew A. Sabitov
On 04.06.2015 14:55, Alex Efros wrote:

> Hi!
>
> On Thu, Jun 04, 2015 at 01:39:57PM +0600, Andrew A. Sabitov wrote:
>> Коллеги, кто может раскрыть секрет: что, хотя бы в теории, может убивать
>> пакеты _до_ iptables???
> Ядро, разумеется. Там тоже есть фильтры пакетов, например проверки source
> route работают в сложных конфигурациях… странновато. Я предпочитаю их
> отключать и реализовывать защиту от спуфинга ручками в iptables.
>
> При этом в hardened настройки ядра по умолчанию для source route
> изменились недавно (https://bugs.gentoo.org/show_bug.cgi?id=534132),
> поэтому я бы рекомендовал явно прописать в /etc/sysctl.conf:
>      net.ipv4.conf.default.rp_filter = 0
>      net.ipv4.conf.all.rp_filter = 0
> и перегрузиться (или выставить этот 0 ручками в /proc или через sysctl для
> всех интерфейсов плюс к default и all).
>

Уже давно сделал :(

  ~ # sysctl -a | grep rp_fil
net.ipv4.conf.all.arp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.arp_filter = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.eth0.arp_filter = 0
net.ipv4.conf.eth0.rp_filter = 0
net.ipv4.conf.eth0/0007.arp_filter = 0
net.ipv4.conf.eth0/0007.rp_filter = 0
net.ipv4.conf.eth0/0008.arp_filter = 0
net.ipv4.conf.eth0/0008.rp_filter = 0
net.ipv4.conf.eth0/0016.arp_filter = 0
net.ipv4.conf.eth0/0016.rp_filter = 0
net.ipv4.conf.eth0/0017.arp_filter = 0
net.ipv4.conf.eth0/0017.rp_filter = 0
net.ipv4.conf.eth0/0018.arp_filter = 0
net.ipv4.conf.eth0/0018.rp_filter = 0
net.ipv4.conf.eth0/0019.arp_filter = 0
net.ipv4.conf.eth0/0019.rp_filter = 0
net.ipv4.conf.eth0/0021.arp_filter = 0
net.ipv4.conf.eth0/0021.rp_filter = 0
net.ipv4.conf.eth0/0032.arp_filter = 0
net.ipv4.conf.eth0/0032.rp_filter = 0
net.ipv4.conf.eth0/0040.arp_filter = 0
net.ipv4.conf.eth0/0040.rp_filter = 0
net.ipv4.conf.eth0/0130.arp_filter = 0
net.ipv4.conf.eth0/0130.rp_filter = 0
net.ipv4.conf.eth0/0131.arp_filter = 0
net.ipv4.conf.eth0/0131.rp_filter = 0
net.ipv4.conf.eth0/0132.arp_filter = 0
net.ipv4.conf.eth0/0132.rp_filter = 0
net.ipv4.conf.eth0/0133.arp_filter = 0
net.ipv4.conf.eth0/0133.rp_filter = 0
net.ipv4.conf.eth0/0134.arp_filter = 0
net.ipv4.conf.eth0/0134.rp_filter = 0
net.ipv4.conf.eth0/0135.arp_filter = 0
net.ipv4.conf.eth0/0135.rp_filter = 0
net.ipv4.conf.eth0/0141.arp_filter = 0
net.ipv4.conf.eth0/0141.rp_filter = 0
net.ipv4.conf.eth0/0144.arp_filter = 0
net.ipv4.conf.eth0/0144.rp_filter = 0
net.ipv4.conf.eth0/0150.arp_filter = 0
net.ipv4.conf.eth0/0150.rp_filter = 0
net.ipv4.conf.eth0/0151.arp_filter = 0
net.ipv4.conf.eth0/0151.rp_filter = 0
net.ipv4.conf.eth0/0152.arp_filter = 0
net.ipv4.conf.eth0/0152.rp_filter = 0
net.ipv4.conf.eth0/0153.arp_filter = 0
net.ipv4.conf.eth0/0153.rp_filter = 0
net.ipv4.conf.eth0/0154.arp_filter = 0
net.ipv4.conf.eth0/0154.rp_filter = 0
net.ipv4.conf.eth0/0155.arp_filter = 0
net.ipv4.conf.eth0/0155.rp_filter = 0
net.ipv4.conf.eth0/0156.arp_filter = 0
net.ipv4.conf.eth0/0156.rp_filter = 0
net.ipv4.conf.eth0/0157.arp_filter = 0
net.ipv4.conf.eth0/0157.rp_filter = 0
net.ipv4.conf.eth0/0158.arp_filter = 0
net.ipv4.conf.eth0/0158.rp_filter = 0
net.ipv4.conf.eth0/0161.arp_filter = 0
net.ipv4.conf.eth0/0161.rp_filter = 0
net.ipv4.conf.eth0/0162.arp_filter = 0
net.ipv4.conf.eth0/0162.rp_filter = 0
net.ipv4.conf.eth0/0181.arp_filter = 0
net.ipv4.conf.eth0/0181.rp_filter = 0
net.ipv4.conf.eth0/0182.arp_filter = 0
net.ipv4.conf.eth0/0182.rp_filter = 0
net.ipv4.conf.eth0/0183.arp_filter = 0
net.ipv4.conf.eth0/0183.rp_filter = 0
net.ipv4.conf.eth0/0184.arp_filter = 0
net.ipv4.conf.eth0/0184.rp_filter = 0
net.ipv4.conf.eth0/0201.arp_filter = 0
net.ipv4.conf.eth0/0201.rp_filter = 0
net.ipv4.conf.eth0/0202.arp_filter = 0
net.ipv4.conf.eth0/0202.rp_filter = 0
net.ipv4.conf.eth0/0203.arp_filter = 0
net.ipv4.conf.eth0/0203.rp_filter = 0
net.ipv4.conf.eth0/0221.arp_filter = 0
net.ipv4.conf.eth0/0221.rp_filter = 0
net.ipv4.conf.eth0/0224.arp_filter = 0
net.ipv4.conf.eth0/0224.rp_filter = 0
net.ipv4.conf.eth1.arp_filter = 0
net.ipv4.conf.eth1.rp_filter = 0
net.ipv4.conf.lo.arp_filter = 0
net.ipv4.conf.lo.rp_filter = 0


Reply | Threaded
Open this post in threaded view
|

Re: Не ходят пинги в локалке. Кто виноват и что делать???

Alex Efros-4
Hi!

Ну тогда методом половинного деления отключать правила файрвола, по
крайней мере все кроме реально необходимых для работы. И упрощать
настройку сети, поотключать другие VLAN-ы, сетевые интерфейсы, etc.
Вероятно, ночью, иначе запишут в диверсанты. :)

--
                        WBR, Alex.

Reply | Threaded
Open this post in threaded view
|

Re: Не ходят пинги в локалке. Кто виноват и что делать???

Andrew A. Sabitov
On 04.06.2015 15:02, Alex Efros wrote:
> Hi!
>
> Ну тогда методом половинного деления отключать правила файрвола, по
> крайней мере все кроме реально необходимых для работы. И упрощать
> настройку сети, поотключать другие VLAN-ы, сетевые интерфейсы, etc.
> Вероятно, ночью, иначе запишут в диверсанты. :)

Фаервол выключал, не помогло :(

Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-user-ru] Не ходят пинги в локалке. Кто виноват и что делать???

Alexey Mishustin
> Фаервол выключал, не помогло :(

Попробовать сбросить роутер на заводские настройки?

--
С уважением,
Алексей Мишустин
Reply | Threaded
Open this post in threaded view
|

Re: Не ходят пинги в локалке. Кто виноват и что делать???

Alex Efros-4
In reply to this post by Andrew A. Sabitov
Hi!

On Thu, Jun 04, 2015 at 03:08:37PM +0600, Andrew A. Sabitov wrote:
> > Ну тогда методом половинного деления отключать правила файрвола, по
> > крайней мере все кроме реально необходимых для работы. И упрощать
> > настройку сети, поотключать другие VLAN-ы, сетевые интерфейсы, etc.
> > Вероятно, ночью, иначе запишут в диверсанты. :)
>
> Фаервол выключал, не помогло :(

Т.е. если перезагрузить роутер с настройками, при которых файрвол и
rp_filter отключены, в один интерфейс пакет входит а из другого не выходит?
Попробовать уменьшить количество поднятых сетевых интерфейсов и VLAN-ов.
Переназначить IP этих машин - у которой был IP x.x.x.19 поставить
x.x.x.40, и наоборот.

--
                        WBR, Alex.

Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-user-ru] Не ходят пинги в локалке. Кто виноват и что делать???

Andrew A. Sabitov
In reply to this post by Alexey Mishustin
On 04.06.2015 15:10, Alexey Mishustin wrote:
>> Фаервол выключал, не помогло :(
> Попробовать сбросить роутер на заводские настройки?

HP DL 360g4p + gentoo


Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-user-ru] Re: [gentoo-user-ru] Не ходят пинги в локалке. Кто виноват и что делать???

Alexey Mishustin
>>> Фаервол выключал, не помогло :(
>>
>> Попробовать сбросить роутер на заводские настройки?
>
>
> HP DL 360g4p + gentoo

Понятно...

--
С уважением,
Алексей Мишустин
Reply | Threaded
Open this post in threaded view
|

Re: Не ходят пинги в локалке. Кто виноват и что делать???

Pavel Labushev-4
In reply to this post by Andrew A. Sabitov
On Thu, 04 Jun 2015 13:39:57 +0600
"Andrew A. Sabitov" <[hidden email]> wrote:

> Hi!
> Коллеги, кто может раскрыть секрет: что, хотя бы в теории, может убивать
> пакеты _до_ iptables???

Есть пара слабых догадок.

accept_redirects и secure_redirects включены?
Что в ip route show cached? Policy-based routing не используете?

Не загружены ли на роутере сетевые модули виртуалбокса или других
супервизоров?

> Перед пинганьем на раутере запускаем:
> tcpdump -n -i eth0.0018 net 172.17.18.0/24 and host 172.16.0.11
> tcpdump -n -i eth1          net 172.17.18.0/24 and host 172.16.0.11

Попробуйте повторить с ключами -p и -e. Проверьте, совпадает ли
мак-адрес назначения в ответах от .19 с мак-адресом на eth0.0018.

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Не ходят пинги в локалке. Кто виноват и что делать???

Denis V. Rybakov
In reply to this post by Andrew A. Sabitov
А с простого начинать пробовали?

Например временно сказать

iptables -I FORWARD --src 172.17.18.0/24 --dst 172.16.0.0/24 -j ACCEPT
iptables -I FORWARD --src 172.16.0.0/24 --dst 172.17.18.0/24 -j ACCEPT

чтобы исключить потенциальные ошибки в правилах iptables и всяких там
ip4_black_list, ip4_white_list_2_inet, формирование которых тут неочевидно.

Обычно самое необъяснимое поведение в итоге связано с самыми простыми и
тупыми ошибками.

Что касается действительно необъяснимых подземных стуков в iptables, я
имел несчастье наблюдать такие случаи, но все они проявлялись при
использовании policy routing.
В обычных конфигурациях все ведет себя стабильно и предсказуемо.

Для адекватного анализа нужен вывод:

arp -a
ip addr list
ip rule list
ip route list
ip route list table local
iptables-save
ipset list

При тестировании пингом и логировании tcpdump лучше использовать фильтр
типа "tcpdump -ni eth1 icmp" чтобы увидеть трансформации пакетов, если
таковые произошли (я надеюсь у вас нет машин, которые постоянно друг
друга пингуют).



04.06.2015 10:39, Andrew A. Sabitov пишет:

> Hi!
> Коллеги, кто может раскрыть секрет: что, хотя бы в теории, может
> убивать пакеты _до_ iptables???
>
> Симптомы:
>
> Есть раутер локальной сети, стоящий между юзерами и DMZ.
> eth1 смотрит в DMZ, на eth0 взведена куча vlan'он, каждый из которых
> смотрит
> в нужный кусочек пользовательской сети. На раутере накручены
> iptables+ipset.
> Шейпер и ebtables не используются
>
> В первом приближении (и с ОЧЕНЬ хорошей точностью) все работает. Но!!!
> Совершенно случайно обнаружил проблему, возникновение которой объяснить
> не могу уже неделю :(
>
> В DMZ есть машина 172.16.0.11 (этот момент не принципиален, т.к.
> пробовал с
> разных машин и даже из разных IP-сетей, как из DMZ, так и
> пользовательских). С
> этой машины пускается пинг на 2 адреса в одной из пользовательских сетей.
> Для определенности, пусть это будут 172.17.18.19 и 172.17.18.40.
>
> Получаем такой результат:
> ===============================================================
> sabitov@fig ~ $ ping 172.17.18.19
> PING 172.17.18.19 (172.17.18.19) 56(84) bytes of data.
> ^C
> --- 172.17.18.19 ping statistics ---
> 6 packets transmitted, 0 received, 100% packet loss, time 5002ms
>
> sabitov@fig ~ $ ping 172.17.18.40
> PING 172.17.18.40 (172.17.18.40) 56(84) bytes of data.
> 64 bytes from 172.17.18.40: icmp_seq=1 ttl=63 time=5.59 ms
> 64 bytes from 172.17.18.40: icmp_seq=2 ttl=63 time=4.90 ms
> ^C
> --- 172.17.18.40 ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1001ms
> rtt min/avg/max/mdev = 4.900/5.247/5.594/0.347 ms
> ===============================================================
>
> Перед пинганьем на раутере запускаем:
> tcpdump -n -i eth0.0018 net 172.17.18.0/24 and host 172.16.0.11
> tcpdump -n -i eth1          net 172.17.18.0/24 and host 172.16.0.11
>
> На eth0.0018 имеем:
> ===============================================================
> 12:38:00.277614 IP 172.16.0.11 > 172.17.18.19: ICMP echo request, id
> 26647, seq 1, length 64
> 12:38:00.283405 IP 172.17.18.19 > 172.16.0.11: ICMP echo reply, id
> 26647, seq 1, length 64
> 12:38:01.280200 IP 172.16.0.11 > 172.17.18.19: ICMP echo request, id
> 26647, seq 2, length 64
> 12:38:01.285974 IP 172.17.18.19 > 172.16.0.11: ICMP echo reply, id
> 26647, seq 2, length 64
> 12:38:02.280152 IP 172.16.0.11 > 172.17.18.19: ICMP echo request, id
> 26647, seq 3, length 64
> 12:38:02.285944 IP 172.17.18.19 > 172.16.0.11: ICMP echo reply, id
> 26647, seq 3, length 64
> 12:38:03.280164 IP 172.16.0.11 > 172.17.18.19: ICMP echo request, id
> 26647, seq 4, length 64
> 12:38:03.285961 IP 172.17.18.19 > 172.16.0.11: ICMP echo reply, id
> 26647, seq 4, length 64
> 12:38:04.280186 IP 172.16.0.11 > 172.17.18.19: ICMP echo request, id
> 26647, seq 5, length 64
> 12:38:04.286543 IP 172.17.18.19 > 172.16.0.11: ICMP echo reply, id
> 26647, seq 5, length 64
> 12:38:05.280201 IP 172.16.0.11 > 172.17.18.19: ICMP echo request, id
> 26647, seq 6, length 64
> 12:38:05.286016 IP 172.17.18.19 > 172.16.0.11: ICMP echo reply, id
> 26647, seq 6, length 64
> 12:38:13.170502 IP 172.16.0.11 > 172.17.18.40: ICMP echo request, id
> 26648, seq 1, length 64
> 12:38:13.175813 IP 172.17.18.40 > 172.16.0.11: ICMP echo reply, id
> 26648, seq 1, length 64
> 12:38:14.172288 IP 172.16.0.11 > 172.17.18.40: ICMP echo request, id
> 26648, seq 2, length 64
> 12:38:14.176868 IP 172.17.18.40 > 172.16.0.11: ICMP echo reply, id
> 26648, seq 2, length 64
> ===============================================================
>
> На eth1:
> ===============================================================
> 12:38:00.277575 IP 172.16.0.11 > 172.17.18.19: ICMP echo request, id
> 26647, seq 1, length 64
> 12:38:01.280166 IP 172.16.0.11 > 172.17.18.19: ICMP echo request, id
> 26647, seq 2, length 64
> 12:38:02.280124 IP 172.16.0.11 > 172.17.18.19: ICMP echo request, id
> 26647, seq 3, length 64
> 12:38:03.280132 IP 172.16.0.11 > 172.17.18.19: ICMP echo request, id
> 26647, seq 4, length 64
> 12:38:04.280154 IP 172.16.0.11 > 172.17.18.19: ICMP echo request, id
> 26647, seq 5, length 64
> 12:38:05.280164 IP 172.16.0.11 > 172.17.18.19: ICMP echo request, id
> 26647, seq 6, length 64
> 12:38:13.170466 IP 172.16.0.11 > 172.17.18.40: ICMP echo request, id
> 26648, seq 1, length 64
> 12:38:13.175902 IP 172.17.18.40 > 172.16.0.11: ICMP echo reply, id
> 26648, seq 1, length 64
> 12:38:14.172256 IP 172.16.0.11 > 172.17.18.40: ICMP echo request, id
> 26648, seq 2, length 64
> 12:38:14.176978 IP 172.17.18.40 > 172.16.0.11: ICMP echo reply, id
> 26648, seq 2, length 64
> ===============================================================
>
> Видно, что с .40 все хорошо, а ответы от .19 не проходят через раутер.
> Возникло подозрение,
> что где-то в iptables я это блокирую, как результат напихал кучу
> правил для логирования
> прохождения пакета по цепочкам.
>
> Это реальный кусок без купюр:
> ===============================================================
> iptables -t raw    -A PREROUTING -s 172.17.18.0/24 -j LOG --log-prefix
> "172.17.18.0 (raw): "
> iptables -t mangle -A PREROUTING -s 172.17.18.0/24 -j LOG --log-prefix
> "172.17.18.0 (mangle): "
> #маркируем прямые обращения к squid-у для блокировки в цепочке INPUT
> iptables -t mangle -A PREROUTING -p TCP -s 172.16.0.0/15 --dport 3128
> -j MARK --set-mark 3128
>
> iptables -t nat -A PREROUTING -s 172.17.18.0/24 -j LOG --log-prefix
> "172.17.18.0 (nat): "
> iptables -t nat -A PREROUTING -p TCP \
>         -s 172.16.0.0/15 \
>         -m set ! --match-set "ip4_direct_http_clients" src \
>         -m set ! --match-set "ip4_all_vlans"  dst \
>         -m set   --match-set "ip4_proxying_port_list" dst \
>                 -j REDIRECT --to-ports 3128
>
>
> iptables -A FORWARD -s 172.17.18.0/24 -j LOG --log-prefix "172.17.18.0
> (1): "
> iptables -A FORWARD -p ALL -m set --match-set "ip4_black_list"
> src      -j DROP
> iptables -A FORWARD -s 172.17.18.0/24 -j LOG --log-prefix "172.17.18.0
> (2): "
>
> iptables -A FORWARD -p ALL ! -s 172.17.32.0/24   -m set --match-set
> "ip4_all_vlans" src    -m set ! --match-set "mac" src,src -m limit
> --limit 3/minute --limit-burst 3 -j LOG   --log-prefix "Wrong MAC-IP
> pair (FORWARD): "
> iptables -A FORWARD -p ALL ! -s 172.17.32.0/24   -m set --match-set
> "ip4_all_vlans" src    -m set ! --match-set "mac" src,src -j DROP
>
> iptables -A FORWARD -s 172.17.18.0/24 -j LOG --log-prefix "172.17.18.0
> (3): "
>
> iptables -A FORWARD -p ALL -m set --match-set "ip4_white_list_2_inet"
> src -j ACCEPT
> iptables -A FORWARD -p ALL -m set --match-set "ip4_white_list_2_inet"
> dst -j ACCEPT
>
> iptables -A FORWARD -p ALL -m addrtype --dst-type
> BROADCAST               -j DROP
>
> iptables -A FORWARD -s 172.17.18.0/24 -j LOG --log-prefix "172.17.18.0
> (4): "
>
> iptables -A FORWARD -p ALL  -m conntrack --ctstate
> ESTABLISHED,RELATED    -j ACCEPT
>
> iptables -A FORWARD -s 172.17.18.0/24 -j LOG --log-prefix "172.17.18.0
> (5): "
>
> iptables -A FORWARD -p TCP  -j forward_tcp_packets
> iptables -A FORWARD -p UDP  -j forward_udp_packets
> iptables -A FORWARD -p ICMP -j forward_icmp_packets
>
> iptables -A FORWARD -s 172.17.18.0/24 -j LOG --log-prefix "172.17.18.0
> (6): "
>
> iptables -A forward_icmp_packets -s 172.17.18.0/24 -j LOG --log-prefix
> "172.17.18.0: "
> iptables -A forward_icmp_packets -p ICMP -j ACCEPT
> ===============================================================
>
> Если верить диаграмме http://inai.de/images/nf-packet-flow.png , то у
> меня должно в первую
> очередь отработать логирование входящего пакета в цепочке PREROUTING
> таблицы raw.
> Дык вот, для ответов от .40 это так и есть, а для .19 -- тишина!
> ===============================================================
> router ~ # grep 172.17.18. /var/log/messages | grep 172.16.0.11
> Jun  4 12:38:13 router kernel: 172.17.18.0 (raw): IN=eth0.0018 OUT=
> MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
> DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=100 PROTO=ICMP
> TYPE=0 CODE=0 ID=26648 SEQ=1
> Jun  4 12:38:13 router kernel: 172.17.18.0 (raw): IN=eth0.0018 OUT=
> MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
> DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=100 PROTO=ICMP
> TYPE=0 CODE=0 ID=26648 SEQ=1
> Jun  4 12:38:13 router kernel: 172.17.18.0 (mangle): IN=eth0.0018 OUT=
> MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
> DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=100 PROTO=ICMP
> TYPE=0 CODE=0 ID=26648 SEQ=1
> Jun  4 12:38:13 router kernel: 172.17.18.0 (1): IN=eth0.0018 OUT=eth1
> MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
> DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=100 PROTO=ICMP
> TYPE=0 CODE=0 ID=26648 SEQ=1
> Jun  4 12:38:13 router kernel: 172.17.18.0 (2): IN=eth0.0018 OUT=eth1
> MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
> DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=100 PROTO=ICMP
> TYPE=0 CODE=0 ID=26648 SEQ=1
> Jun  4 12:38:13 router kernel: 172.17.18.0 (3): IN=eth0.0018 OUT=eth1
> MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
> DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=100 PROTO=ICMP
> TYPE=0 CODE=0 ID=26648 SEQ=1
> Jun  4 12:38:13 router kernel: 172.17.18.0 (4): IN=eth0.0018 OUT=eth1
> MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
> DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=100 PROTO=ICMP
> TYPE=0 CODE=0 ID=26648 SEQ=1
> Jun  4 12:38:14 router kernel: 172.17.18.0 (raw): IN=eth0.0018 OUT=
> MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
> DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=101 PROTO=ICMP
> TYPE=0 CODE=0 ID=26648 SEQ=2
> Jun  4 12:38:14 router kernel: 172.17.18.0 (raw): IN=eth0.0018 OUT=
> MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
> DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=101 PROTO=ICMP
> TYPE=0 CODE=0 ID=26648 SEQ=2
> Jun  4 12:38:14 router kernel: 172.17.18.0 (mangle): IN=eth0.0018 OUT=
> MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
> DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=101 PROTO=ICMP
> TYPE=0 CODE=0 ID=26648 SEQ=2
> Jun  4 12:38:14 router kernel: 172.17.18.0 (1): IN=eth0.0018 OUT=eth1
> MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
> DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=101 PROTO=ICMP
> TYPE=0 CODE=0 ID=26648 SEQ=2
> Jun  4 12:38:14 router kernel: 172.17.18.0 (2): IN=eth0.0018 OUT=eth1
> MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
> DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=101 PROTO=ICMP
> TYPE=0 CODE=0 ID=26648 SEQ=2
> Jun  4 12:38:14 router kernel: 172.17.18.0 (3): IN=eth0.0018 OUT=eth1
> MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
> DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=101 PROTO=ICMP
> TYPE=0 CODE=0 ID=26648 SEQ=2
> Jun  4 12:38:14 router kernel: 172.17.18.0 (4): IN=eth0.0018 OUT=eth1
> MAC=00:13:21:ae:e7:4b:00:1d:b3:91:29:a0:08:00 SRC=172.17.18.40
> DST=172.16.0.11 LEN=84 TOS=0x00 PREC=0x00 TTL=63 ID=101 PROTO=ICMP
> TYPE=0 CODE=0 ID=26648 SEQ=2
> ===============================================================
>
> Эта проблема касается не только пингов, а трафика "вообще". Например,
> через раз срабатывает обход устройств по SNMP.
>
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [gentoo-user-ru] Не ходят пинги в локалке. Кто виноват и что делать???

Denis V. Rybakov
In reply to this post by Alexey Mishustin
Евгений Ваганович, перелогиньтесь.


04.06.2015 12:10, Alexey Mishustin пишет:

>> Фаервол выключал, не помогло :(
> Попробовать сбросить роутер на заводские настройки?
>


Reply | Threaded
Open this post in threaded view
|

Re: Не ходят пинги в локалке. Кто виноват и что делать???

Andrew A. Sabitov
In reply to this post by Andrew A. Sabitov
On 04.06.2015 20:16, Pavel Labushev wrote:
> Есть пара слабых догадок.
>
> accept_redirects и secure_redirects включены?

И вот тут Вы попали в 10ку!
все accept_redirects были 0, а secure_redirects были 1
Как только я их выключил, так все заработало!

СПАСИБО!!!



Reply | Threaded
Open this post in threaded view
|

Re: Не ходят пинги в локалке. Кто виноват и что делать???

Pavel Labushev-4
On Thu, 04 Jun 2015 23:08:49 +0600
"Andrew A. Sabitov" <[hidden email]> wrote:


> > accept_redirects и secure_redirects включены?
>
> И вот тут Вы попали в 10ку!
> все accept_redirects были 0, а secure_redirects были 1
> Как только я их выключил, так все заработало!

О, как. Рад, что помогло.

<offtopic>
Вообще, слово secure в secure_redirects сбивает с толку. Небезопасной
является обработка и редиректов с произвольным мак-адресом источника, и
рекдиректов с правильным мак-адресом гейта для соответствующего маршрута
(за что как раз отвечает secure_redirects), ведь подделать мак-адрес
гейта практически всегда так же легко, как использовать любой другой.
Поэтому secure_redirects и accept_redirects лучше отключать всегда и
сразу.
</offtopic>

attachment0 (836 bytes) Download Attachment