Esta questão é uma provável duplicata deNão é possível conectar-se ao servidor local a partir de outros dispositivos (conectados via wifi) quando o servidor está conectado via wifi, que nunca recebeu uma resposta aceita.
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 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, tudo bem.
Dispositivos locais conectados à mesma rede Wi-Fi que o servidor não conseguem se conectar de maneira confiável. Acabei de reiniciar o servidor, o roteador E o PC conectado por Wi-Fi e, vários minutos depois, o PC conseguiu se conectar com êxito... mas antes das reinicializações, as conexões falharam (sem rota para o host) e já duravam vários dias. Tendo visto esse padrão antes, tenho quase certeza de que eles começarão a falhar novamente.
Meus pensamentos estão indo na direção de que isso tenha algo a ver com renovações de DHCP, mas não sei como consertar isso.
Perguntas do comentarista:
"O que significa" não é possível conectar de forma confiável "?"
Quando para de funcionar, as tentativas parecem falhas de roteamento. Os pings atingem o tempo limite, a maioria dos outros protocolos relata 'nenhuma rota para o host', os logs do servidor não mostram nenhuma tentativa de conexão.
"O servidor possui interfaces Ethernet e WIFI?"
Não mais; ele está rodando em WIFI porque a interface Ethernet integrada morreu durante uma tempestade com raios e o sistema operacional não a reconhece mais como 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 iptablespor enquanto porque quando as conexões falham, nenhuma tentativa de conexão é registrada (o iptables nunca tem a chance de agir na tentativa).
"Você tem um único roteador executando também as funções de ponto de acesso, 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ídos? Um bom diagrama com todos os dispositivos e endereços IP podem ser úteis."
Mais detalhes sobre isso quando estiver 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 do modem a cabo para o roteador e para o servidor. O modem a cabo não está no modo bridge puro (em vez disso, está fazendo DHCP com o roteador como seu único cliente) porque um monte de coisas desmoronaram quando tentei isso (possivelmente estranheza nos requisitos de autenticação do ISP) e não lutei com isso porque não era um problema, mas pode não ser mais o caso.