Esta pregunta es un probable duplicado deNo se puede conectar al servidor local desde otros dispositivos (conectados mediante wifi) cuando el servidor está conectado mediante wifi, que nunca recibió una respuesta aceptada.
Tengo un servidor Linux, actualmente conectado a la red vía wifi. Funciona y es accesible (por ejemplo, a través de ssh) desde fuera de mi red doméstica a través de un servicio DNS dinámico y NAT basado en enrutador y reenvío de puertos. El enrutador es un Linksys EA4500.
Las PC locales conectadas al enrutador pueden conectarse vía ssh exitosamente, aunque deben usar la IP local (192.168.1.122, estática a través de reserva DHCP en el enrutador), porque el enrutador no enrutará el tráfico interno a su IP externa. Muy bien, está bien.
Los dispositivos locales conectados a la misma red wifi que el servidor no pueden conectarse de manera confiable. Acabo de reiniciar el servidor, el enrutador Y la PC conectada a wifi, y varios minutos después la PC pudo conectarse exitosamente... pero antes de los reinicios, las conexiones fallaron (no había ruta al host) y así habían sido durante varios días. Habiendo visto este patrón antes, estoy bastante seguro de que empezarán a fallar nuevamente.
Mis pensamientos apuntan a que esto tiene algo que ver con las renovaciones de DHCP, pero no sé cómo solucionarlo.
Preguntas del comentarista:
"¿Qué significa "no se puede conectar de manera confiable"?"
Cuando deja de funcionar, los intentos tienen la apariencia de errores de enrutamiento. Los pings se agotan, la mayoría de los demás protocolos informan que "no hay ruta al host", los registros del servidor no muestran ningún intento de conexión.
"¿El servidor tiene interfaces Ethernet y WIFI?"
Ya no; se ejecuta en WIFI porque la interfaz Ethernet integrada murió durante una tormenta eléctrica y el sistema operativo ya no la reconoce como presente.
"Proporcione el resultado 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
Omitiendo iptablespor ahora porque cuando las conexiones fallan, no se registra ningún intento de conexión (iptables nunca tiene la oportunidad de actuar en el intento).
"¿Tiene un solo enrutador que realiza también las funciones de punto de acceso, o tiene varios enrutadores, o un enrutador y un punto de acceso separados? ¿Qué direcciones IP está utilizando para varios dispositivos y cómo se asignan? Un buen diagrama con Todos los dispositivos y direcciones IP pueden ser útiles."
Más detalles sobre esto cuando esté físicamente presente. Pero hay un módem por cable y un enrutador/WAP separado detrás de eso. El enrutador está ejecutando DHCP en 192.168.1.*. Reenvío de puertos desde módem por cable a enrutador y servidor. El cable módem no está en modo puente puro (en cambio, está haciendo DHCP con el enrutador como su único cliente) porque un montón de cosas fallaron cuando lo intenté (posiblemente una rareza en los requisitos de autenticación del ISP) y no he luchado con porque no era un problema, pero tal vez ya no sea así.