Não é possível conectar-se ao servidor conectado via wifi a partir do cliente conectado via wifi na mesma rede

Question

Esta pergunta é uma provável duplicata de Não é possível conectar-se ao servidor local de outros dispositivos (conectados via wifi) quando o servidor está conectado via wifi , que nunca recebeu uma resposta aceita.

Eu tenho um servidor Linux, atualmente conectado à rede via wifi. Ele funciona e é acessível (por exemplo, via ssh) de fora da minha rede doméstica por meio de um serviço DNS dinâmico e NAT baseado em roteador e encaminhamento de porta. O roteador é um Linksys EA4500.

Os PCs locais conectados ao roteador podem se conectar via ssh com sucesso, embora eles devam usar o IP local (192.168.1.122, estático via reserva DHCP no roteador), porque o roteador não roteará o tráfego interno para seu IP externo. Justo o suficiente, tudo bem.

Dispositivos locais conectados à mesma rede Wi-Fi que o servidor não pode conectar de forma confiável. Eu apenas reiniciei o servidor, o roteador e o PC conectado ao Wi-Fi, e vários minutos depois o PC conseguiu se conectar com sucesso ... mas antes das reinicializações, as conexões falharam (nenhuma rota para o host) e ficaram por vários dias. Tendo visto esse padrão antes, tenho quase certeza de que eles vão começar a falhar novamente.

Meus pensamentos estão tendendo na direção disso, tendo algo a ver com as renovações do DHCP, mas não sei como consertá-lo.

Perguntas dos comentadores:

"O que" não é possível conectar de maneira confiável "significa"?

Quando ele para de funcionar, as tentativas têm a aparência de falhas de roteamento. Os pings excedem o tempo limite, a maioria dos outros protocolos informa "sem rota para o host", os registros do servidor não mostram nenhuma tentativa de conexão.

"O servidor tem interfaces Ethernet e WIFI?"

Não mais; Ele está rodando em WIFI porque a interface Ethernet onboard morreu durante uma tempestade elétrica e o sistema operacional não mais o reconhece como estando presente.

"Por favor, forneça a saída de ifconfig e iptables."

    lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
            inet 127.0.0.1  netmask 255.0.0.0
            inet6 ::1  prefixlen 128  scopeid 0x10<host>
            loop  txqueuelen 0  (Local Loopback)
            RX packets 31149  bytes 5871934 (5.5 MiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 31149  bytes 5871934 (5.5 MiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

    wlp1s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
            inet 192.168.1.122  netmask 255.255.255.0  broadcast 192.168.1.255
            inet6 fe80::5627:1eff:fe1a:7535  prefixlen 64  scopeid 0x20<link>
            ether 54:27:1e:1a:75:35  txqueuelen 1000  (Ethernet)
            RX packets 2063063  bytes 379558678 (361.9 MiB)
            RX errors 0  dropped 0  overruns 0  frame 0
            TX packets 784726  bytes 119478321 (113.9 MiB)
            TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Omitindo iptables por enquanto, porque quando as conexões falham, nenhuma tentativa de conexão é registrada (iptables nunca tem a chance de agir na tentativa).

"Você tem um único roteador executando os deveres de ponto de acesso também, ou você tem vários roteadores ou roteador e ponto de acesso separados? Quais endereços IP você está usando para vários dispositivos, e como eles são atribuído? Um bom diagrama com todos os dispositivos e endereços IP pode ser útil. "

Mais detalhes sobre isso quando estou fisicamente presente. Mas há um modem a cabo e um roteador / WAP separado por trás disso. O roteador está fazendo DHCP em 192.168.1. *. Encaminhamento de porta de modem a cabo para roteador para servidor. O modem a cabo não está no modo bridge puro (em vez disso, ele está fazendo DHCP com o roteador como seu único cliente) porque um monte de coisas se desfez quando tentei isso (possivelmente estranheza nos requisitos de autenticação do ISP) e eu não lutei com porque não foi um problema, mas isso pode não ser mais o caso.