LINUX.ORG.RU
Форум — Admin  

Настройка vlan как на коммутаторе

 , ,


0

1

Имею сервер с CentOS8. Основная сетка 172.16.0.7/24, еще есть несколько vlan 10.1.0.5/16, 10.2.0.5/16 и т.д.

Ключ в норме

[root@localhost /]# cat /proc/sys/net/ipv4/ip_forward

1

iptables тоже вроде в норме

[root@localhost /]# 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

[root@localhost /]#

Сервер подключен к коммутатору, который все сетки видит.

Проблема - не могу получить даже пинг c IP не родной подсети, т.е. если у другой машины, к примеру, IP 10.1.0.103, то видит она только 10.1.0.5, а другие IP, к примеру, 10.2.0.5 и 172.16.0.7 - не видит.

С коммутатора к любому IP можно достучаться, но там и так понятно - все сети в нем прописаны.

При этом в сети есть еще и циска, работающая как маршрутизатор - отлично с любого IP на любой все пересылается.

Подскажите куда копать? Может еще чего не включено?



Последнее исправление: sober_dev (всего исправлений: 4)
← CentOS 8 Stream and kernel rt
Как поменять айпи на ссылку к сервису в локальной сети? →
Ответ на: комментарий от FireFighter

Да, на коммутаторе основная сетка тоже 172.16.0.1/24 и все vlan прописаны. Коммутаторы из разных подсетей друг-друга видят, даже если на них не прописаны другие vlan. Затык именно с сервером. До этого стоял другой сервер с AltLinux такая же проблема была.

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

Вот часть конфига

VLAN

enable pvid auto_assign config vlan default delete 1-27 config vlan default add untagged 15-20,23-24 config vlan default advertisement enable create vlan net1 tag 2 config vlan net1 add tagged 15-21,24 config vlan net1 add untagged 1-9,11-14 advertisement disable create vlan net2 tag 3 config vlan net2 add tagged 15-20,22,24 advertisement disable create vlan net3 tag 4 config vlan net3 add tagged 15-20,23-24 config vlan net3 add untagged 10 advertisement disable create vlan net4 tag 5 config vlan net4 add tagged 15-20,23-24 advertisement disable disable qinq disable gvrp disable vlan_trunk config gvrp 1-9,11-14 state disable ingress_checking enable >acceptable_frame admit_all pvid 2 config gvrp 10 state disable ingress_checking enable >acceptable_frame admit_all pvid 4 config gvrp 15-27 state disable ingress_checking enable >acceptable_frame admit_all pvid 1

Сервер подключен к 24 порту. На нем прописана как родная сетка 172.16.0.0/24, так и тегированные vlan.

Коммутатор D-Link DGS-3627G. Нашел вот тему https://forum.dlink.ru/viewtopic.php?f=2&t=175030 но включение глобальной опции VLAN Trunk Global Settings и указание портов, ситуацию не изменило.

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

На 24 порту есть:

  • untagged PVID 1
  • tagged VID 2
  • tagged VID 3
  • tagged VID 4
  • tagged VID 5

Правильно?

На сервере ip на правильных VID? MAC’и других устройств из VLAN’ов на сервере видны?

FireFighter ★★★
()
Последнее исправление: FireFighter (всего исправлений: 1)
Ответ на: комментарий от sober_dev

Хоть бы показал «ip li» на сервере.

Запусти 'tcpdump -nei ethXXX -с 5 vlan' и посмотри наличие входящих пакетов c vlan-тегами. Их отсутствие говорит о неправильной настройке порта на коммутаторе.

Если сетевой интерфейс на сервере подключен к бриджу, то на брижде нужно разрешить хождение vlan-трафика.

vel ★★★★★
()
Ответ на: комментарий от FireFighter

Да, все правильно, как вы написали.

Две недели назад настроил и установил другой сервер, тоже с CentOS, но на нем только родная сетка 172.16.0.22/24 - его видит из любого vlan. Пакеты между vlan ходят, однозначно. Собственно хрен бы с такой ситуацией, но на первом сервере находится личный кабинет абонента и иметь кучу IP для разных подсетей несколько напряжно для абонентов. Они думать не любят. Хотелось одну ссылку на один IP разместить.

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

[root@localhost /]# ip li

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether ac:1f:6b:49:24:be brd ff:ff:ff:ff:ff:ff

3: eno2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN mode DEFAULT group default qlen 1000 link/ether ac:1f:6b:49:24:bf brd ff:ff:ff:ff:ff:ff

4: eno1.4@eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether ac:1f:6b:49:24:be brd ff:ff:ff:ff:ff:ff

5: eno1.3@eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether ac:1f:6b:49:24:be brd ff:ff:ff:ff:ff:ff

6: eno1.5@eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether ac:1f:6b:49:24:be brd ff:ff:ff:ff:ff:ff

7: eno1.2@eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether ac:1f:6b:49:24:be brd ff:ff:ff:ff:ff:ff

8: eno1.21@eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether ac:1f:6b:49:24:be brd ff:ff:ff:ff:ff:ff

[root@localhost /]#

Бриджа нет.

tcpdump - спасибо, посмотрю.

sober_dev
() автор топика
Ответ на: комментарий от vel 
[root@localhost /]# ip -d li sh dev eno1.2
7: eno1.2@eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether ac:1f:6b:49:24:be brd ff:ff:ff:ff:ff:ff promiscuity 0 minmtu 0 maxmtu 65535
    vlan protocol 802.1Q id 2 <REORDER_HDR> addrgenmode none numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535
[root@localhost /]#

[root@localhost /]# ip ro
default via 172.16.0.1 dev eno1 proto static metric 100
default via 10.3.0.1 dev eno1.4 proto static metric 400
default via 10.2.0.1 dev eno1.3 proto static metric 401
default via 10.4.0.1 dev eno1.5 proto static metric 402
default via 10.1.0.1 dev eno1.2 proto static metric 403
10.1.0.0/16 dev eno1.2 proto kernel scope link src 10.1.0.5 metric 403
10.2.0.0/16 dev eno1.3 proto kernel scope link src 10.2.0.5 metric 401
10.3.0.0/16 dev eno1.4 proto kernel scope link src 10.3.0.5 metric 400
10.4.0.0/16 dev eno1.5 proto kernel scope link src 10.4.0.5 metric 402
10.250.1.128/25 dev eno1.21 proto kernel scope link src 10.250.1.130 metric 404
172.16.0.0/24 dev eno1 proto kernel scope link src 172.16.0.7 metric 100
[root@localhost /]#

[root@localhost /]# ip ru
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default
[root@localhost /]#
sober_dev
() автор топика
Ответ на: комментарий от vel 
[root@localhost /]# tcpdump -nei eno1 -c 5 vlan
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
14:04:22.768346 50:d4:f7:3d:f6:55 > ac:1f:6b:49:24:be, ethertype 802.1Q (0x8100), length 80: vlan 2, p 0, ethertype IPv4, 10.1.2.173.simp-all > 10.1.0.5.domain: 54986+ AAAA? games.roblox.com. (34)
14:04:22.768953 18:31:bf:a3:f6:04 > ac:1f:6b:49:24:be, ethertype 802.1Q (0x8100), length 80: vlan 3, p 0, ethertype IPv4, 10.2.1.174.49454 > 10.2.0.5.domain: 2+ A? dns.msftncsi.com. (34)
14:04:22.769194 ac:1f:6b:49:24:be > 18:31:bf:a3:f6:04, ethertype 802.1Q (0x8100), length 556: vlan 3, p 0, ethertype IPv4, 10.2.0.5.domain > 10.2.1.174.49454: 2 1/13/14 A 131.107.255.255 (510)
14:04:22.770371 94:de:80:36:8b:08 > ac:1f:6b:49:24:be, ethertype 802.1Q (0x8100), length 99: vlan 2, p 0, ethertype IPv4, 10.1.1.176.23299 > 10.1.0.5.domain: 62733+ A? pull-cmaf-l16-tt01.tiktokcdn-us.com. (53)
14:04:22.770819 ac:1f:6b:49:24:be > 94:de:80:36:8b:08, ethertype 802.1Q (0x8100), length 552: vlan 2, p 0, ethertype IPv4, 10.1.0.5.domain > 10.1.1.176.23299: 62733 4/13/4 CNAME pull-cmaf-l16-tt01.tiktokcdn-us.com.akamaized.net., CNAME a1390.z.akamai.net., A 2.16.20.50, A 2.16.20.17 (506)
5 packets captured
22 packets received by filter
0 packets dropped by kernel
[root@localhost /]#
sober_dev
() автор топика
Ответ на: комментарий от sober_dev

Мля.... 

default via 172.16.0.1 dev eno1 proto static metric 100
default via 10.3.0.1 dev eno1.4 proto static metric 400
default via 10.2.0.1 dev eno1.3 proto static metric 401
default via 10.4.0.1 dev eno1.5 proto static metric 402
default via 10.1.0.1 dev eno1.2 proto static metric 403
У тебя должен быть 1 шлюз по умолчанию!

Убери все, что через vlan-ы.

vel ★★★★★
()

Как-то всё сумбурно в твоих объяснениях.

Ну вот сервер вроде-как нормально во всех VLAN-ах виден.

А вот что значит

т.е. если у другой машины, к примеру, IP 10.1.0.103, то видит она только 10.1.0.5, а другие IP, к примеру, 10.2.0.5 и 172.16.0.7 - не видит.

Ну вот знает твоя «машинка» 10.1.0.103, что 10.1.0.5 в её сети, и пинг идёт.

Но вот что у тебя настроено на этой же «машинке», что бы она видела 10.2.0.5 и 172.16.0.7? Настройки «сервера» тут ни причём.

Если на «машинке» нет других сетей, то она у тебя (так понимаю) перенаправит трафик на 10.1.0.1. Кто это?

AlexVR ★★★★★
()
Последнее исправление: AlexVR (всего исправлений: 2)
Ответ на: комментарий от vel

Так, у меня уже мозг закипел…

Убрать через /etc/sysconfig/network-scripts ?

В ifcfg-eno1

TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=none
IPADDR=172.16.0.7
PREFIX=24
GATEWAY=172.16.0.1
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=eno1
UUID=fab35c68-584a-411b-b389-440e0a3beb4b
DEVICE=eno1
ONBOOT=yes

В ifcfg-eno1.2

VLAN=yes
TYPE=Vlan
PHYSDEV=eno1
VLAN_ID=2
REORDER_HDR=yes
GVRP=no
MVRP=no
HWADDR=
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=none
IPADDR=10.1.0.5
PREFIX=16
GATEWAY=10.1.0.1
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=eno1.2
UUID=a3f52c5c-d42e-49ed-91a0-f494859f390d
DEVICE=eno1.2
ONBOOT=yes
ZONE=public

В остальных приблизительно то же.

Убрать GATEWAY= во всех vlan ?

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

Но вот что у тебя настроено на этой же «машинке», что бы она видела 10.2.0.5 и 172.16.0.7? Настройки «сервера» тут ни причём.

Эта «машинка» замечательно видит цисковские 172.16.0.10, 10.1.0.10, 10.2.0.10… и т.д. Также замечательно видит посторонние коммутаторы из других vlan, у которых, к примеру, прописаны 172.16.0.50 и 10.4.0.4. По любому IP могу обращаться. Но вот на линксовый сервер заходит только в IP из своей подсети.

Если на «машинке» нет других сетей, то она у тебя (так понимаю) перенаправит трафик на 10.1.0.1. Кто это?

Шлюз это, коммутатор D-Link DGS-3627G к 24 порту которого как раз подключен «проблемный» сервер.

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

Эта «машинка» замечательно видит цисковские 172.16.0.10, 10.1.0.10, 10.2.0.10… и т.д. Также замечательно видит посторонние коммутаторы из других vlan, у которых, к примеру, прописаны 172.16.0.50 и 10.4.0.4. По любому IP могу обращаться. Но вот на линксовый сервер заходит только в IP из своей подсети.

Так сделай

tracepath -n 10.2.0.5
tracepath -n 10.2.0.10
tracepath -n 172.16.0.50
...
AlexVR ★★★★★
()
Ответ на: комментарий от sober_dev

как раз подключен «проблемный» сервер.

Только он как раз и не выглядит в твоём описании проблемным.

Он же не является маршрутизатором.

За доступность IP-адресов из других подсетей отвечают настройки «машинки» и «шлюза».

AlexVR ★★★★★
()
Ответ на: комментарий от AlexVR 
[root@comp-sempron-processor-06ba28 ~]# tracepath -n 10.2.0.5
 1:  10.1.1.101                                            0.190ms pmtu 1500
 1:  10.1.0.1                                              1.532ms asymm 35
 1:  10.1.0.1                                              1.753ms asymm 35
 2:  no reply
 3:  no reply
 4:  no reply
 5:  no reply
 6:  no reply
 7:  no reply
 8:  no reply
 9:  no reply
10:  no reply
11:  no reply
12:  no reply
13:  no reply
14:  no reply
15:  no reply
16:  no reply
17:  no reply
18:  no reply
19:  no reply
20:  no reply
21:  no reply
22:  no reply
23:  no reply
24:  no reply
25:  no reply
26:  no reply
27:  no reply
28:  no reply
29:  no reply
30:  no reply
31:  no reply
     Too many hops: pmtu 1500
     Resume: pmtu 1500
[root@comp-sempron-processor-06ba28 ~]#

[root@comp-sempron-processor-06ba28 ~]# tracepath -n 10.2.0.10
 1:  10.1.1.101                                            0.189ms pmtu 1500
 1:  10.1.0.1                                              1.411ms asymm 35
 1:  10.1.0.1                                              1.231ms asymm 35
 2:  10.2.0.10                                             5.308ms reached
     Resume: pmtu 1500 hops 2 back 255
[root@comp-sempron-processor-06ba28 ~]#


[root@comp-sempron-processor-06ba28 ~]# tracepath -n 172.16.0.50
 1:  10.1.1.101                                            0.193ms pmtu 1500
 1:  10.1.0.1                                              1.254ms asymm 35
 1:  10.1.0.1                                              1.230ms asymm 35
 2:  172.16.0.50                                           6.401ms reached
     Resume: pmtu 1500 hops 2 back 29
[root@comp-sempron-processor-06ba28 ~]#
sober_dev
() автор топика
Ответ на: комментарий от AlexVR 
[root@comp-sempron-processor-06ba28 ~]# ping 10.2.0.5
PING 10.2.0.5 (10.2.0.5) 56(84) bytes of data.
^C
--- 10.2.0.5 ping statistics ---
24 packets transmitted, 0 received, 100% packet loss, time 23184ms

Ловил:

[root@localhost utm5plus]# tcpdump -nei eno1  vlan > /home/utm5plus/tcpdump.txt

В результате вижу

16:31:45.764638 34:08:04:a4:82:02 > ac:1f:6b:49:24:be, ethertype 802.1Q (0x8100), length 102: vlan 3, p 0, ethertype IPv4, 10.1.1.101 > 10.2.0.5: ICMP echo request, id 8947, seq 1, length 64

16:31:46.772644 34:08:04:a4:82:02 > ac:1f:6b:49:24:be, ethertype 802.1Q (0x8100), length 102: vlan 3, p 0, ethertype IPv4, 10.1.1.101 > 10.2.0.5: ICMP echo request, id 8947, seq 2, length 64

16:31:47.780543 34:08:04:a4:82:02 > ac:1f:6b:49:24:be, ethertype 802.1Q (0x8100), length 102: vlan 3, p 0, ethertype IPv4, 10.1.1.101 > 10.2.0.5: ICMP echo request, id 8947, seq 3, length 64

Пакеты все же доходят.

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

Да. При условии, что GATEWAY=172.16.0.1 - реальный шлюз в инет.

Я бы начал с простого - удалил временно лишние маршруты вручную и посмотрел бы на результат. 

ip ro del default via 10.3.0.1 dev eno1.4 proto static metric 400
ip ro del default via 10.2.0.1 dev eno1.3 proto static metric 401
ip ro del default via 10.4.0.1 dev eno1.5 proto static metric 402
ip ro del default via 10.1.0.1 dev eno1.2 proto static metric 403

vel ★★★★★
()
Ответ на: комментарий от vel

Да. При условии, что GATEWAY=172.16.0.1 - реальный шлюз в инет.

На этом шлюзе запросы в интернеты пересылаются на циску, т.е. с 172.16.0.1 на 172.16.0.10. Соответственно с 10.1.0.1 на 10.1.0.10 и т.д.

Я бы начал с простого - удалил временно лишние маршруты вручную и посмотрел бы на результат.

Днем сервер постоянно в работе. Буду пробовать ночью.

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

А вот теперь вопрос, что должен сделать сервер, что бы ответить на пинг от 10.1.1.101 на 10.2.0.5?

Как должен выглядеть ответный пакет, и куда он должен быть отправлен?

  1. К серверу пришёл пакет, который ужасен по содержимому (из одной его сети пытаются пинговать другую).
  2. А ответ отправлять не пойми куда.

В лучшем случае, это безобразие зарубит rp_filter.

AlexVR ★★★★★
()
Ответ на: комментарий от sober_dev

В вашей сети кавардак.

Зачем вам вообще VLAN-ы?

На коммутаторах это каким-то образом работает?

Вот именно, что каким-то. И это настораживать должно.

Можно сделать предположение, что НЕКОРРЕКТНЫЙ пакет был отброшен на стороне сервера (например, rp_filter сработал).

Зачем надо было разбивать на VLAN-ы, что бы потом тут же собирать их вместе, да ещё и с перекрестиями?

Когда клиент и сервер у тебя пингуются в одной подсети - это хорошо.

Но когда ты пытаешься соединять клиента с сервером через сторонний интерфейс, где одно направление через роутер, а обратное через сеть. То это что-то про гланды и отверстие ниже поясницы.

AlexVR ★★★★★
()
Ответ на: комментарий от AlexVR

Но когда ты пытаешься соединять клиента с сервером через сторонний интерфейс, где одно направление через роутер, а обратное через сеть. То это что-то про гланды и отверстие ниже поясницы.

Соглашусь, что это необычно. Когда я собирал это чудо в первом варианте с десяток лет назад, то у меня совсем не было опыта. Потом пришлось повторить на новом сервере, потому что совместимость нужно было обеспечить. Сейчас бы сделал по другому, но увы - имею, что имею. Пытаюсь исправить ситуацию доступными средствами.

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

Я не стал рисковать рабочим сервером. Поднял тестовую машину, создал такие же vlan, как на рабочем сервере. Естественно название устройств другое:

[root@localhost /]# nmcli c sh -a
NAME      UUID                                  TYPE      DEVICE
enp2s0    e16ede7b-da92-47e3-b8c2-76e0ece5bcf2  ethernet  enp2s0
enp2s0.2  a3f52c5c-d42e-49ed-91a0-f494859f390d  vlan      enp2s0.2
enp2s0.3  735ba5e5-c7af-4c40-95d8-82ad22e91fc4  vlan      enp2s0.3
enp2s0.4  4ae92a37-bde7-4d00-9d67-51ccd22a180c  vlan      enp2s0.4
enp2s0.5  9373fb08-df7e-4ca1-ad36-0bc3839d92f6  vlan      enp2s0.5

[root@localhost /]# ip ro
default via 172.16.0.1 dev enp2s0 proto static metric 100
10.1.0.0/16 dev enp2s0.2 proto kernel scope link src 10.1.0.6 metric 400
10.2.0.0/16 dev enp2s0.3 proto kernel scope link src 10.2.0.6 metric 401
10.3.0.0/16 dev enp2s0.4 proto kernel scope link src 10.3.0.6 metric 402
10.4.0.0/16 dev enp2s0.5 proto kernel scope link src 10.4.0.6 metric 403
172.16.0.0/24 dev enp2s0 proto kernel scope link src 172.16.0.8 metric 100
[root@localhost /]#

Результат отрицательный - по прежнему пингует только адрес из подсети машины.

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

И при этом пинг не работает для любого хоста из сетей подключенных через vlan-интерфейсы ?

Ну, вот захожу на коммутатор 10.1.0.89 и с него пинг:

                       DES-3200-10 Fast Ethernet Switch
                            Command Line Interface

                          Firmware: Build 4.51.B007
           Copyright(C) 2017 D-Link Corporation. All rights reserved.
UserName:admin
PassWord:********

DES-3200-10:admin#ping 10.1.0.6
Command: ping 10.1.0.6

Reply from 10.1.0.6, time<10ms
Reply from 10.1.0.6, time<10ms
Reply from 10.1.0.6, time<10ms
Reply from 10.1.0.6, time<10ms

 Ping Statistics for 10.1.0.6
 Packets: Sent =4, Received =4, Lost =0


DES-3200-10:admin#ping 10.2.0.6
Command: ping 10.2.0.6

Request timed out.
Request timed out.
Request timed out.
Request timed out.

 Ping Statistics for 10.2.0.6
 Packets: Sent =5, Received =0, Lost =5


DES-3200-10:admin#

Захожу на коммутатор 10.2.0.68 и с него пинг:

                       DES-3200-10 Fast Ethernet Switch
                            Command Line Interface

                          Firmware: Build 4.51.B007
           Copyright(C) 2017 D-Link Corporation. All rights reserved.
UserName:admin
PassWord:**********

DES-3200-10:admin#ping 10.2.0.6
Command: ping 10.2.0.6

Reply from 10.2.0.6, time<10ms
Reply from 10.2.0.6, time<10ms
Reply from 10.2.0.6, time<10ms
Reply from 10.2.0.6, time<10ms

 Ping Statistics for 10.2.0.6
 Packets: Sent =4, Received =4, Lost =0


DES-3200-10:admin#ping 10.1.0.6
Command: ping 10.1.0.6

Request timed out.
Request timed out.
Request timed out.
Request timed out.

 Ping Statistics for 10.1.0.6
 Packets: Sent =5, Received =0, Lost =5


DES-3200-10:admin#

А рабочий сервер отвечает ?

Рабочий сервер ведет себя также. Я на нем маршруты пока не трогал.

tcpdump-от vlan-фреймы видны?

Пинговал:

[root@comp-sempron-processor-06ba28 ~]# ping 10.2.0.6
PING 10.2.0.6 (10.2.0.6) 56(84) bytes of data.
^C
--- 10.2.0.6 ping statistics ---
17 packets transmitted, 0 received, 100% packet loss, time 16126ms

[root@comp-sempron-processor-06ba28 ~]#

Ловил:

[root@localhost home]# tcpdump -nei enp2s0  vlan > /home/tcpdump.txt
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C654 packets captured
660 packets received by filter
0 packets dropped by kernel
[root@localhost home]#

В результате вижу

07:24:27.987528 34:08:04:a4:82:02 > 94:de:80:dd:58:cc, ethertype 802.1Q (0x8100), length 102: vlan 3, p 0, ethertype IPv4, 10.1.1.101 > 10.2.0.6: ICMP echo request, id 21968, seq 1, length 64

07:24:28.994440 34:08:04:a4:82:02 > 94:de:80:dd:58:cc, ethertype 802.1Q (0x8100), length 102: vlan 3, p 0, ethertype IPv4, 10.1.1.101 > 10.2.0.6: ICMP echo request, id 21968, seq 2, length 64

07:24:30.002448 34:08:04:a4:82:02 > 94:de:80:dd:58:cc, ethertype 802.1Q (0x8100), length 102: vlan 3, p 0, ethertype IPv4, 10.1.1.101 > 10.2.0.6: ICMP echo request, id 21968, seq 3, length 64

Ну, и т.д. сколько их там наловило.

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

Все, нашел причину:

[root@localhost home]# sysctl net.ipv4.conf | grep rp_filter
net.ipv4.conf.all.arp_filter = 0
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.arp_filter = 0
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.enp2s0.arp_filter = 0
net.ipv4.conf.enp2s0.rp_filter = 0
net.ipv4.conf.enp2s0/2.arp_filter = 0
net.ipv4.conf.enp2s0/2.rp_filter = 0
net.ipv4.conf.enp2s0/3.arp_filter = 0
net.ipv4.conf.enp2s0/3.rp_filter = 0
net.ipv4.conf.enp2s0/4.arp_filter = 0
net.ipv4.conf.enp2s0/4.rp_filter = 0
net.ipv4.conf.enp2s0/5.arp_filter = 0
net.ipv4.conf.enp2s0/5.rp_filter = 0
net.ipv4.conf.lo.arp_filter = 0
net.ipv4.conf.lo.rp_filter = 0

Когда сбросил:

[root@localhost home]# sysctl -w net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.all.rp_filter = 0
[root@localhost home]#

Пинг пошел. Теперь нужно подумать, чем это может грозить нехорошим, т.к. товарищ AlexVR - аккуратно назвал меня рукожопом, за данное начинание. С чем я в принципе не спорю.

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

rp_filter позволяет регулировать ситуацию когда у тебя есть асимметричный роутинг.

Скорее всего хосты находящиеся в этих vlan-ах отвечают через свой шлюз и все ответы например приходят из vlan1

vel ★★★★★
()

У тебя уже работает маршрутизация между виланами (то ли на маршрутизаторе, то ли на L3 коммутаторе, ты сам похоже не вполне понимаешь). Зачем подключать сервер к нескольким виланам? Удали все эти интерфейсы eno1.x, оставь один лишь eno1 и живи спокойно.

iliyap ★★★★★
()
Ответ на: комментарий от iliyap

Давно бы уже удалил, но там еще и DNS поднят, а у абонентов прописаны 10.1.0.5, 10.2.0.5 и т.д. Как вариант еще остается локальный домен на BIND запилить, чтобы к нему обращались все, а уж с какой сети он сам разберется.

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

Ну он первым и должен был быть под подозрением.

Смотрим что было.

  1. Клиент с 10.1.0.103 хочет отправить пинг на 10.2.0.5
  2. Т.к. это не в его подсети, то он отправляет пакет на маршрутизатор 10.1.0.1
  3. Маршрутизатор получает пакет из сети 10.1.х.х в сеть 10.2.х.х и перенаправляет его.
  4. Сервер получает пакет от 10.1.0.103 через интерфейс 10.2.0.5 и охреневает, куда он должен будет отправить ответ? Если через интерфейс 10.1.x.x то получаются разные пути и это похоже на атаку или цикл в сети. А через 10.2.х.х он отправить не может, т.к. не знает маршрута до 10.1.х.х через 10.2.0.5, да и смысла не будет, т.к. есть прямой маршрут.

Таким образом, получаем ситуацию, когда пинг заходит через один интерфейс, а ответ выходит через другой. А многие сценарии с multipath требуют более внимательного контроля и дополнительной настройки, т.к. дефолтные настройки могут прикрывать те или иные пути атаки.

AlexVR ★★★★★
()
← CentOS 8 Stream and kernel rt
Admin
Как поменять айпи на ссылку к сервису в локальной сети? →