Centos 7 с двумя сетевыми интерфейсами в одной сети, один из которых не отвечает на пинг извне
У меня только что установлен centos7 с 2 активными интерфейсами в той же сети, как это IP-шоу addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 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
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 40:a8:f0:1e:50:54 brd ff:ff:ff:ff:ff:ff
inet 213.78.236.190/26 brd 213.78.236.191 scope global eno1
valid_lft forever preferred_lft forever
inet6 fe80::42a8:f0ff:fe1e:5054/64 scope link
valid_lft forever preferred_lft forever
3: eno2: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN qlen 1000
link/ether 40:a8:f0:1e:50:55 brd ff:ff:ff:ff:ff:ff
4: eno3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 40:a8:f0:1e:50:56 brd ff:ff:ff:ff:ff:ff
inet 213.78.236.175/26 brd 213.78.236.191 scope global eno3
valid_lft forever preferred_lft forever
inet6 fe80::42a8:f0ff:fe1e:5056/64 scope link
valid_lft forever preferred_lft forever
5: eno4: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN qlen 1000
link/ether 40:a8:f0:1e:50:57 brd ff:ff:ff:ff:ff:ff
таблица маршрутизации выглядит следующим образом:
default via 213.78.236.129 dev eno1
213.78.236.128/26 dev eno1 proto kernel scope link src 213.78.236.190
213.78.236.128/26 dev eno3 proto kernel scope link src 213.78.236.175
проблема в том, что у меня есть доступ только к интерфейсу с 213.78.236.190 из внешнего мира, то есть из другой сети. Я могу пинг-это, подключиться к SSH сделать все, что угодно. Но на 213.78.236.175 я могу подключиться только из локальной сети. Он не отвечает на пинг извне, я вижу пакеты, поступающие по tcpdump, но ответа нет.
iptables чистый
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
Я знаю, что это должно работать, потому что это заменяет centos6 с подобной конфигурацией и на centos 6, работавшей с самого начала, просто настройте ip на обоих интерфейсах и gw по умолчанию на одном интерфейсе. Я отключил NetworkManager, я подозревал, что он что-то напутал. Я включил ip_forwarding в sysctl.conf
cat /proc/sys/net/ipv4/ip_forward
1
даже если я не думаю, что мне нужно. Я вижу пакеты icmp, приходящие извне в tcpdump, но ничего не выходит. Ниже описано, что произойдет, если я пингуюсь с машины 213.65.165.84. Ip, который я пингую, является 213.78.236.175
tcpdump -i eno3 -n -p| grep ICMP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno3, link-type EN10MB (Ethernet), capture size 65535 bytes
10:52:09.531494 IP 213.65.165.84 > 213.78.236.175: ICMP echo request, id 16686, seq 23, length 64
10:52:10.531489 IP 213.65.165.84 > 213.78.236.175: ICMP echo request, id 16686, seq 24, length 64
10:52:11.531492 IP 213.65.165.84 > 213.78.236.175: ICMP echo request, id 16686, seq 25, length 64
10:52:12.531483 IP 213.65.165.84 > 213.78.236.175: ICMP echo request, id 16686, seq 26, length 64
tcpdump -i eno1 -n -p| grep ICMP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), capture size 65535 bytes
и это то, что происходит, если я пинг другой IP 213.78.236.190 с той же машины
tcpdump -i eno1 -n -p| grep ICMP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), capture size 65535 bytes
10:58:45.973485 IP 213.65.165.84 > 213.78.236.190: ICMP echo request, id 16705, seq 5, length 64
10:58:45.973522 IP 213.78.236.190 > 213.65.165.84: ICMP echo reply, id 16705, seq 5, length 64
10:58:46.973483 IP 213.65.165.84 > 213.78.236.190: ICMP echo request, id 16705, seq 6, length 64
10:58:46.973515 IP 213.78.236.190 > 213.65.165.84: ICMP echo reply, id 16705, seq 6, length 64
После того, как kasperd заметил, я обновил запись с помощью tcpdump с параметром -p, чтобы предотвратить случайный режим, и проверил в wireshark, чтобы увидеть, что запросы ping приходят с правильным mac-адресом. Таким образом, проблема заключается в том, что ядро по какой-то причине отбрасывает пакеты.
3 ответа
Хотя вы упомянули, что iptables был чистым, вы упомянули, что вы недавно установили CentOS 7, поэтому мне было интересно, активен ли программный брандмауэр по умолчанию для CentOS 7, firewalld, и, если да, блокирует ли он эхо-ответы ICMP для одного из его зоны. Например, если firewalld активен, для его GUI запуск firewall-config и проверка "ICMP Filter" для каждой зоны покажет, есть ли фильтры для "echo-request" и "echo-reply". Если он блокировал их, вы все равно могли видеть эхо-запросы с помощью tcpdump. Вы также можете проверить с помощью "firewall-cmd --list-all-zone", ища строку "icmp-blocks" для каждой зоны.
Проблема заключается в изменении RHEL 6 и более поздних версий, а также изменения настроек rp_filter в ядре. Посмотрите на http://access.redhat.com/solutions/53031
Я могу придумать одно объяснение, которое соответствует всем описанным симптомам. На маршрутизаторе была настроена статическая запись ARP, сопоставляющая этот IP-адрес с MAC-адресом интерфейса на старом сервере.
Когда пакеты поступают извне, маршрутизатор не отправляет никакого запроса ARP, поскольку у него уже есть запись для этого IP-адреса.
Коммутатор при получении пакетов будет искать MAC-адрес назначения в своей CAM, но не найдет его, потому что старый сервер с таким MAC-адресом больше не находится в этой сети. Таким образом, коммутатор будет транслировать пакеты на все интерфейсы (кроме того, от которого он получил пакет).
Когда вы запускаете tcpdump на сервере, интерфейс по умолчанию переключается в случайный режим. В случайном режиме отображаются все пакеты, даже если их адрес назначения не совпадает. Если вы использовали -p флаг tcpdump, сетевой интерфейс будет игнорировать эти пакеты и не отправлять их ядру.
Ядро доставляет пакеты в tcpdump, но стек IP не обрабатывает их из-за неправильного MAC-адреса назначения.
При отправке эхо-запроса с другого хоста в локальной сети запись ARP на маршрутизаторе не влияет ни на что. Другой хост отправит запрос ARP, а ваш сервер отправит ответ ARP. В этих случаях эхо-запросы будут отправлены на правильный MAC-адрес. Таким образом, эхо-запросы будут видны только правильному интерфейсу, и, поскольку MAC-адрес назначения является правильным, стек IP будет обрабатывать эти пакеты.