Этот вопрос, скорее всего, является дубликатом сообщения « Не удается подключиться к локальному серверу с других устройств (подключенных через Wi-Fi)», когда сервер подключен через Wi-Fi, который никогда не получал принятый ответ.
У меня есть сервер Linux, в настоящее время подключен к сети через Wi-Fi. Он работает и доступен (например, через ssh) из-за пределов моей домашней сети через службу динамического DNS и NAT на основе маршрутизатора и переадресацию портов. Маршрутизатор является Linksys EA4500.
Локальные ПК, подключенные к маршрутизатору, могут успешно подключаться через ssh, хотя они должны использовать локальный IP-адрес (192.168.1.122, статический через резервирование DHCP на маршрутизаторе), поскольку маршрутизатор не будет направлять внутренний трафик на свой внешний IP-адрес. Достаточно справедливо, это нормально.
Локальные устройства, подключенные к той же сети Wi-Fi, что и сервер, не могут надежно подключиться. Я только что перезагрузил сервер, маршрутизатор И ПК, подключенный к Wi-Fi, и через несколько минут ПК смог успешно подключиться ... но до перезагрузки соединения не удалось (маршрут к хосту отсутствовал), и он был в течение нескольких дней. Видя этот шаблон раньше, я уверен, что они снова начнут терпеть неудачу.
Мои мысли склоняются к тому, что это как-то связано с обновлениями DHCP, но я не знаю, как это исправить.
Вопросы комментатора:
Что значит "не может надежно соединиться"?"
Когда он перестает работать, попытки выглядят как ошибки маршрутизации. Пинг истекает, большинство других протоколов сообщают «нет маршрута к хосту», журналы сервера не показывают попытки подключения.
«Есть ли на сервере интерфейсы Ethernet и WIFI?"
Уже нет; он работает по WIFI, потому что встроенный интерфейс Ethernet умер во время грозы, и ОС больше не распознает его как присутствующий.
"Пожалуйста, предоставьте вывод ifconfig и 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
Пропуск iptables на данный момент, потому что при сбое соединения попытка подключения не регистрируется (iptables никогда не имеет возможности действовать при попытке).
«У вас есть один маршрутизатор, выполняющий также обязанности точки доступа, или у вас есть несколько маршрутизаторов, или отдельный маршрутизатор и точка доступа? Какие IP-адреса вы используете для различных устройств и как они назначены? Хорошая схема со всеми устройствами и IP-адресами может быть полезна ».
Более подробно об этом, когда я физически присутствую. Но за этим стоит кабельный модем и отдельный маршрутизатор /WAP. Маршрутизатор делает DHCP на 192.168.1.*. Переадресация портов с кабельного модема на маршрутизатор на сервер. Кабельный модем не находится в режиме чистого моста (вместо этого, он делает DHCP с маршрутизатором в качестве единственного клиента), потому что куча вещей развалилась, когда я попробовал это (возможно, странность в требованиях аутентификации провайдера), и я не боролся с это потому, что это не было проблемой, но это может быть уже не так.