Не удается подключиться к локальному серверу с других устройств (подключенных через Wi-Fi), когда сервер подключен через Wi-Fi

Question

Есть домашняя сеть: 192.168.1.0/24 , шлюз по умолчанию 192.168.1.1 (DHCP)

Есть веб-сервер, который работает на хосте, позволяет называть хост "сервером".

Есть несколько устройств, которые подключены к маршрутизатору через Wi-Fi (клиенты).

Проблема: клиенты не могут подключиться к серверу, когда он подключен к сети через Wi-Fi. Но они могут подключиться к нему, когда он подключен через Ethernet.

«не могу подключиться» означает:

• http ://192.168.1.15/myservice - "Ой! Google Chrome не может подключиться к 192.168.1.15 "

• telnet/ping 192.168.1.15 - "Хост назначения недоступен"

Сервер: Ubuntu 12.04 x86_64 (ядро 3.8.0-35-generic)

# UFW статус

Status: inactive

# iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Конфигурация сети Ethernet сервера

# ifconfig eth2

inet addr:192.168.1.14  Bcast:192.168.1.255  Mask:255.255.255.0

# netstat -rn

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 eth2
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth2
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth2

Конфигурация сети Wi-Fi сервера

# ifconfig eth3

inet addr:192.168.1.15  Bcast:192.168.1.255  Mask:255.255.255.0

# netstat -rn

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 eth3
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth3
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 eth3

JIC, я могу подключиться к своему интерфейсу Wi-Fi из (!) сервер (но, вероятно, он просто подключается через петлевой интерфейс).

В чем проблема?

Answer 1

Как ваш сервер получает свой IP-адрес?

Как правило, DHCP назначает разные IP-адреса разным интерфейсам, несмотря на то, что рассматриваемые сетевые адаптеры могут принадлежать одному и тому же компьютеру.

На самом деле, как DHCP-сервер может знать, что два разных сетевых адаптера принадлежат одному и тому же компьютеру? Все DHCP-сервер видит MAC-адреса двух карт, и они разные. Следовательно, он назначает разные IP-адреса.

В качестве теста попробуйте

  http://192.168.1.15/myservice 

используя вместо 15 IP-адрес веб-сервера, когда он подключен через Wi-Fi. Могу поспорить, это будет работать.

На сегодняшний день самым простым решением будет оставить сервер всегда подключенным через одну и ту же плату NIC. Второе простейшее решение - включить резервирование адресов для MAC-адреса сетевой карты веб-сервера и подделать этот же адрес на беспроводной карте веб-сервера, когда он подключен к Wi-Fi.

Если вас смущает слово « подделка», это означает, что вы хотите замаскировать истинный MAC-адрес беспроводной карты и сделать так, чтобы у него был другой MAC-адрес. Программы для этого есть во всех ОС.

Answer 2

Интерфейс Wi-Fi может запускаться ПОСЛЕ запуска системных служб, тогда как подключение к Ethernet устанавливается ДО запуска служб.

Если ваш веб-сервер явно привязан к адресу Wi-Fi и запускается раньше, чем Wi-Fi, он может попытаться открыть прослушивающий порт, выйти из строя и просто полностью забыть об этом IP-адресе, то есть никаких подключений впоследствии.

Помните, что Wi-Fi должен пройти проверку подлинности на вашем маршрутизаторе, прежде чем что-либо сможет его использовать (включая ВСЕ системные службы). Если вы делаете это вручную после запуска системы, это подозрительно.

Answer 3

Старый вопрос старый, но все же ... Я заметил, что никто не упомянул о возможности привязки веб-сервера к определенному IP-адресу, несмотря на то, что показанная ошибка невозможности подключения указана для 192.168.1.15, а eth2 явно настроен для 192.168.1.14 и eth3 для 192.168.1.15. В таком случае следует убедиться, что их веб-сервер связан с правильным IP-адресом или настроен на использование любого доступного IP-адреса.

Answer 4

Хотя я думаю, что все уже предоставленные ответы являются хорошими догадками, я думаю, что здесь есть две возможности. Либо Даниэль Б. был чем-то с идеей "изоляции AP", либо есть проблемы с arp.

Я не мог не помочь вам рассказать, как проверить настройки "изоляции" ваших маршрутизаторов, потому что я уверен, что это в значительной степени зависит от того, существует ли эта функциональность в вашем конкретном маршрутизаторе и какой интерфейс предлагает ваш маршрутизатор. Поскольку этот вопрос довольно старый, я не думаю, что получу ответ и на него, но если ОП ответит, я бы хотел его изучить и предоставить инструкции по проверке / исправлению.

Я могу рассказать вам, как проверить, если это проблема с ARP. Если вы используете клиенты Windows, запустите административную командную строку. В Windows 10 нажмите "Пуск", введите "cmd", затем щелкните правой кнопкой мыши командную строку и выберите "Запуск от имени администратора" в контекстном меню. В командной строке вы можете ввести «arp -a»;

C:\Windows\system32>arp -a 192.168.1.15

Interface: 192.168.0.123 --- 0x13
Internet Address      Physical Address      Type
192.168.1.15          00-50-56-3e-ce-3e     dynamic

Убедитесь, что указанный MAC-адрес соответствует MAC-адресу вашей беспроводной карты. Если это не так, вы можете попробовать очистить кеш arp ...

C:\Windows\system32>arp /d 192.168.1.15

Попробуйте снова пропинговать адрес сервера 192.168.1.15 с вашего клиента, а затем снова проверить кэш arp, чтобы узнать, получает ли он правильный MAC-адрес для беспроводной карты на вашем сервере. Если этого не произойдет, возможно, вам понадобится изменить некоторые настройки беспроводного маршрутизатора, и, опять же, я не могу оказать большую помощь в этом без дополнительной информации.