Eu tenho um centos7 acabado de instalar com 2 interfaces ativas na mesma rede como esta ip addr show
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
tabela de roteamento se parece com isso ip route show
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
o problema é que eu tenho acesso apenas à interface com o 213.78.236.190 do mundo externo, ou seja, outra rede. Eu posso pingar, conectar ao ssh fazer o que for. Mas no 213.78.236.175 eu só posso conectar da rede local. Ele não responde ao ping do lado de fora, eu posso ver os pacotes chegando no tcpdump mas sem resposta.
iptables está limpo
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
Eu sei que isso deve funcionar porque isso substitui um centos6 com configuração similar e no centos 6 trabalhado desde o início basta configurar o ip nas duas interfaces e o gw padrão em uma interface. Eu desabilitei o NetworkManager e suspeitei que ele estava bagunçando alguma coisa. Ativei o ip_forwarding em sysctl.conf
cat /proc/sys/net/ipv4/ip_forward
1
mesmo se eu não acho que preciso. Eu posso ver os pacotes icmp vindo de fora no tcpdump mas nada sai. Abaixo está o que acontece se eu pingar da máquina 213.65.165.84. O ip estou ping é 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
e isso é o que acontece se eu pingar o outro ip 213.78.236.190 da mesma máquina
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
Após o kasperd observado atualizei a postagem com o tcpdump com a opção -p para evitar o modo promíscuo e verifiquei no wireshark para ver se as requisições de ping chegam com o endereço mac correto. Então o problema parece ser que o kernel descarta os pacotes por algum motivo.
O problema é uma alteração com o RHEL 6 e superior e as configurações do rp_filter alteradas no kernel. Olhe para link
Eu posso pensar em uma explicação que corresponda a todos os sintomas descritos até agora. No roteador, uma entrada ARP estática foi configurada, mapeando esse endereço IP para o endereço MAC da interface em seu servidor antigo.
Quando os pacotes chegam de fora, o roteador não envia nenhuma solicitação ARP porque já possui uma entrada para esse endereço IP.
O switch ao receber os pacotes procurará o endereço MAC de destino em sua CAM, mas não o encontrará porque o antigo servidor com esse endereço MAC não está mais nessa rede. O switch, então, transmitirá os pacotes em todas as interfaces (exceto a que recebeu o pacote).
Quando você executa o tcpdump no servidor, a interface é, por padrão, alternada para o modo promíscuo. No modo promíscuo, todos os pacotes são exibidos, mesmo que o endereço de destino não esteja correspondendo. Se você usou o -p flag para o tcpdump, a interface de rede ignoraria esses pacotes e não os enviaria para o kernel.
O kernel envia os pacotes para o tcpdump, mas a pilha IP não os processa devido ao endereço MAC de destino errado.
Ao enviar uma solicitação de eco de outro host na LAN, a entrada ARP no roteador não afeta nada. O outro host enviará uma solicitação ARP e seu servidor enviará uma resposta ARP. Nesses casos, as solicitações de eco serão enviadas para o endereço MAC correto. Assim, as solicitações de eco serão vistas apenas pela interface correta e, como o endereço MAC de destino está correto, a pilha de IP processará esses pacotes.
Tags networking linux