A caixa do Gentoo não pode cURL ou ping após reiniciar o net.eth1

Question

o seguinte é completamente desconcertante para mim. Atualmente, temos uma caixa do gentoo que atua como nosso servidor LAMP, DNS e DHCP. Isso é atribuído a um IP estático na rede. Este servidor está conectado diretamente à internet através de um roteador BT BusinessHub. O servidor também está conectado a um painel de conexão / porta de conexão que conecta o escritório restante (cerca de 10 PCs) ao servidor.

Tudo foi planejado até o outro dia em que o servidor foi reiniciado. Por algum motivo, apenas partes da acessibilidade de rede estão disponíveis, dependendo de qual dispositivo de rede foi reiniciado pela última vez. Reiniciar o net.eth0 permite que o servidor do Office cURL, ping, etc, mas impede que todos os PCs da rede acessem a Internet. Em seguida, reiniciando net.eth1 restaura toda a internet para a rede, mas pára o servidor de curling, ping, etc novamente.

No entanto, mesmo quando o servidor não pode fazer ping, curl, etc, eu ainda posso conectar remotamente o SSH e MySQL remotos da linha de comando do servidor para outros servidores externos que possuímos.

Aqui está o meu mapa de rotas (o roteador é 192.168.1.254):

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
0.0.0.0         192.168.1.254   0.0.0.0         UG    0      0        0 eth1

Aqui está meu /etc/conf.d/net:

iface_eth0="192.168.1.99 broadcast 192.168.1.255 netmask 255.255.255.0"
iface_eth1="dhcp"

Nenhum dos itens acima foi alterado no entanto. As coisas acabaram de deixar de funcionar corretamente, o que me faz pensar que é uma regra recém-adicionada do Iptables. Aqui está a tabela Filtro do Iptables:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       tcp  --  ##.##.##.##          anywhere            tcp dpt:ssh
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:2199
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:3199
ACCEPT     tcp  --  ##.###.###.##        anywhere            tcp dpt:http
ACCEPT     tcp  --  ###.###.##.##        anywhere            tcp dpt:2199
ACCEPT     tcp  --  ##.###.###.###       anywhere            tcp dpt:http
ACCEPT     tcp  --  ##.###.##.##         anywhere            tcp dpt:http
ACCEPT     tcp  --  ##.###.###.###       anywhere            tcp dpt:3128
ACCEPT     udp  --  ##.###.###.###       anywhere            udp dpt:3128
ACCEPT     tcp  --  ##.###.###.###       anywhere            tcp dpt:http
ACCEPT     tcp  --  ##.###.###.###       anywhere            tcp dpt:https
Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             ##.###.###.##
DROP       all  --  anywhere             ##.###.###.##
ACCEPT     all  --  anywhere             anywhere            state NEW,ESTABLISHED
Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  anywhere             anywhere            udp spt:2199
ACCEPT     udp  --  anywhere             anywhere            udp spt:4817
ACCEPT     udp  --  anywhere             anywhere            udp spt:4819
ACCEPT     udp  --  anywhere             anywhere            udp spt:3199

Ajude agradeço apreciada.

    

Answer 1

Você percebe que você tem eth0 e eth1 efetivamente configurados para a mesma sub-rede?

192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1

iface_eth0="192.168.1.99 broadcast 192.168.1.255 netmask 255.255.255.0"
iface_eth1="dhcp"

Mude a sub-rede do seu roteador para 192.168.0.0/24, ou alguma outra sub-rede além de 192.168.1.0/24, reinicie a eth1 e isso deve resolvê-la. A menos que as duas interfaces estejam realmente na mesma rede - e não estão - elas não devem ser configuradas para a mesma sub-rede.

Além disso, todo o tráfego passa pelo seu servidor para chegar ao roteador?

Se assim for, recomendo apenas ligar a ponte no seu roteador para dar ao seu servidor um endereço IP público. Veja: link - isso evitará totalmente o problema, embora, como não estou familiarizado com o seu roteador, você pode evitar isso; eles chamam de ponte, parece que pode ser um passthrough, onde ele ainda faz a autenticação (o BT faz PPPoE / PPPoA auth?), mas transmite as informações do DHCP.

Ter duas configurações de sub-redes NAT é um desperdício se você não usar / precisar.

    

Answer 2

Pelo jeito parece que suas interfaces estão configuradas para não permitir o redirecionamento por padrão, então quando a interface é reiniciada, ele pára o redirecionamento mostrando o tipo de problema que você está tendo.

Tente adicionar isso ao seu /etc/sysctl.conf

Adicione / descomente as seguintes linhas:

net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1

Se você tiver um endereço de Internet dinâmico, provavelmente desejará ativar isso:

net.ipv4.ip_dynaddr = 1

Isso deve resolver seu problema