Ip адрес не указан в одной подсети с lan ip адресом укажите другое значение

Обновлено: 06.07.2024

Здравствуйте!
Нужна помощь в настройке маршрутизации.
Имеется сеть с шлюзом на Windows Server 2008 с настроенной маршрутизацией между офисами и доступом в Интернет.
WiFi роутер подключен к основной сети через порт WAN с ip 192.168.0.128. Локальная сеть на роутере в 254 подсети.

Не могу настроить маршрутизацию с 0 подсети на 254 подсеть.
На шлюзе 192.168.0.1 прописываю маршрут 192.168.254.0 с указанием шлюза 192.168.0.128, ничего не работает, ни пинг, ни трассировка. При этом пинг 192.168.0.128 проходит удачно. Где может быть зарыта собака?

Таблица маршрутов шлюза 192.168.0.1 во вложении.

Маршруты роутера 192.168.0.128:

Роутер не дает настроить статический маршрут на подсеть, в которой находится порт WAN. Этот маршрут уже автоматически прописан.
Трассировка и пинг подсети 0 с роутера проходит успешно. От роутера 192.168.0.1 пишите маршрут до 254й сети: 192.168.254.0 255.255.255.0 192.168.0.128. От роутера 192.168.0.128 пишите обратный маршрут 192.168.0.0 255.255.255.0 (интерфейс 0й сети в вашем облаке 192.168.0.0/24).

Какой IP на Wi-Fi роутере от 254 подсети на LAN?

От роутера 192.168.0.1 пишите маршрут до 254й сети: 192.168.254.0 255.255.255.0 192.168.0.128. От роутера 192.168.0.128 пишите обратный маршрут 192.168.0.0 255.255.255.0 (интерфейс 0й сети в вашем облаке 192.168.0.0/24). Ваша проблема в том, что у вас не прямой линк от 128 IP до 1го. Посмотрите что за оборудование у вас в облаке 0.0/24 и напишите маршрут от 128 адреса до адреса в облаке. Вам достаточно прописать маршрут от 0й подсети до 254й. И все всем будет доступно. Вопрос только в том, как клиенты 0й подсети будут получать пакеты. Если бы вы "разоблачили" все оборудование сети 192.168.0.0/24, то я бы подсказал более точно Дело в том, что на одном и том же роутере, именно L3 роутере, не может существовать два интерфейса в одной подсети. Это похоже на ваше облако 0.0/24. Роутер создан чтобы разграничивать широковещ. домены. Напишите что за линки идут в облако от 192.168.0.1 и от 192.168.0.128 и их IP адреса. Или у вас там просто свитч стоит один? Если облако и есть свитч, то все должно работать без проблем с одним лишь маршрутом до 254й подсети, так как для роутера из 254й подсети 0я сеть есть connected. Единственный гражданин, которому нужна помощь в маршрутах, это 192.168.0.1. Если кто то не пингуется, проверьте настройки портов свита. Напишите кто кого не пингует и главное, откуда. ICMP пакеты то на роутере с IP адресом 192.168.0.1 разрешены?
Кстати, если на компе 192.168.0.30 прописать маршрут до 254й подсети с указанием IP 192.168.0.128 и если свитч не настроен вовсе и все порты в default vlan, то и роутер то 192.168.0.1 для общения между подсетями не нужен Все будет работать напрямую через 128й роутер.

В по схеме в облаке стоят обычные коммутаторы, никаких дополнительных маршрутизаторов там нет.
Не проходит пинг от 0 подсети на 254 с любого узла в 0 подсети. На 192.168.0.30 прописывал маршрут до 128 шлюза, не помогло. На шлюзе 192.168.0.1 прописан маршрут 192.168.254.0 MASK 255.255.255.0 192.168.0.128. В качестве интерфейса маршрутизация выбирает интерфейс в 0 подсети (192.168.0.1).

Пинг с 192.168.254.1 на 192.168.0.X проходит успешно. Трассировка с 254 подсети на 0 подсеть тоже проходит успешно.
Не проходит пинг с любого узла подсети 0 на подсеть 254.
На шлюзе 192.168.0.1 нет запрета пакетов ICMP.
Фаервол на WiFi 192.168.0.128 отключен, любые экраны и блокировки пакетов тоже отключены.

Вопрос частично решился. Прописал Альтернативный DNS-сервер для клиентов 254 подсети 192.168.0.1. Пинг пошел, трассировка тоже.
Только 192.168.254.1 так и не пингуется( На счет "пингуется" вы имеете в виду открываются сайты?
Возможно на роутере с IP 192.168.0.128 просто закрыты ICMP в LAN. Если клиенты за ним доступны, то ничего страшного)

Если пинги из 254й подсети проходят до 0й, то как хосты 0й подсети отправляют вам их обратно неудачно?
Есть точный вариант проверить что не так.
Если машина 192.168.254.100 пингует 192.168.0.30, а наоборот нет, то делаем следующее:
Если пингует, то на роутере 192.168.254.1 проверьте таблицу arp, принадлежащую интерфейсу 192.168.0.128 в локалке 0.0/24. MAC адрес от IP 192.168.0.30 совпадает с MAC адресом машины 192.168.0.30? Если нет - то у вас появились воры в сети. Если да, то скорее всего машина 192.168.0.30 блокирует icmp пакеты частично. ICMP Request запрещены(поэтому эта машина не может отправлять пинги), ICMP Reply разрешены(поэтому она может отвечать на пинг хостов из 254й подсети). Если роутер простенький, то за NAT'ом хосты будут доступны, если знать подсеть и прописать на запрашиваемой машине маршрут до нее. На простых роутерах нет правил, которые претят форвардинг и инпут пакетов, запрещающих dstnat. Проверено, работает) А с адреса 192.168.0.1 пинги возвращаются от 192.168.254.1 или .100?

Если роутер простенький, то за NAT'ом хосты будут доступны, если знать подсеть и прописать на запрашиваемой машине маршрут до нее. На простых роутерах нет правил, которые претят форвардинг и инпут пакетов, запрещающих dstnat. Проверено, работает)

А по моему, как раз, простым роутерам фиолетово и они будут маскарадить - натить, все пакеты вылетающие из WAN интерфейса.
Собственно, этим и объясняется условие автора - что компы находящиеся ЗА роутером, видит компы WAN интерфейса самого роутера.
А вот, компы находящиеся со стороны WAN - внутреннюю LAN сеть не видят, т.к. вполне вероятно, обратные пакеты из LAN - сегмента роутера - просто натятся и в них подменяется src-адрес.
Автору запустить WireShark на компьютере 0-й подсети и попробовать попинговать 254-ю сеть.
Как же не видят когда статик рут явно указан на интерфейс 192.168.0.128 для 254й сети? Если NAT подменит src адрес хоста локалки, то пакет все равно будет доставлен по назначению. Только что лабу запускал, работает.

Как же не видят когда статик рут явно указан на интерфейс 192.168.0.128 для 254й сети? Если NAT подменит src адрес хоста локалки, то пакет все равно будет доставлен по назначению. Только что лабу запускал, работает.

Пакет доставлен обратно будет, но будет доставлен с другим src-адресом) Не 254.128 к примеру, а с 0.128 (то есть с адресом WAN-интерфейса роутера стоящего на границе сетей 192.168.0.0/24 и 192.168.254.0/24
Ну и комп, не признает, что это пакет от узла 254.128) к к которому он обращался
Я это прекрасно понимаю) но вот пакет доставился после обратного src маскарадинга) Попробуй лабу собрать?
И все это если есть NAT. А если просто две подсети разнесенные по интерфейсам, то проблема может быть от фаерволла до vlan на свитчах.

Я это прекрасно понимаю) но вот пакет доставился после обратного src маскарадинга) Попробуй лабу собрать?
И все это если есть NAT. А если просто две подсети разнесенные по интерфейсам, то проблема может быть от фаерволла до vlan на свитчах.

В лабе, на IOL на Cisco да) Он не маскарадит Но, вот как поведет себя бытовой роутер. Тут вопрос остается открытым.
Предлагаю, все таки дождаться комментария автора, насчет включения/выключения у него NAT на его роутере.

Провел эксперимент на реальных железках:
С одной стороны стоял роутер, отдающий адреса по dhcp(Роутер А), с другой стороны второй роутер ловил этот адрес на свой wan интерфейс(Роутер Б), LAN за которым уходил в inside nat. Подключил смартфон ко роутеру Б, чтобы в локалке был хотя бы какой то хост. В обоих роутерах разрешил icmp в LAN и до WAN.
Без маршрута на роутера А до LAN роутера Б, хосты роутера Б пинговали хосты роутера А через NAT. Это было проверено и подтверждено тем, что в arp таблице роутера А был MAC и IP адрес, который роутер А выдал по dhcp роутеру Б на WAN интерфейс. Пинг от А до Б не проходил(очевидно, потому что А не знает LAN Б).
С маршрутом на роутере А до LAN роутера Б, хост(смартфон) в LAN роутера Б стал доступен роутеру А и хосту(компу) LAN роутера А.
Wireshark'ом был пойман icmp трафик роутера А, указывающий на то, что хосту из LAN роутера А на пинг отвечает не outside NAT IP на WAN интерфейсе роутера Б, а локальный IP роутера Б (смартфон). Сам маскарадинг был(таблица arp не изменилась).
Думаю трансляции не произошло в анализаторе потому, что wireshark ловит тот destination при reply, который был при request и это отображает. В виртуальной среде source адрес подменяется внешним интерфейсом и пинги по прежнему возвращаются от другого destination адреса изначально. Вот такие факты. Трансляция до интернета на роутере Б проходит как положено, судя по nat таблице.

Так или иначе у меня получилась связь с маршрутом от сайта А до Б. Единственное что мешало: отсутствие маршрута и запрет icmp на LAN сегменте.

Возможно автор открыл icmp на WAN интерфейсе 192.168.0.128, но не на LAN 192.168.254.0/24, ибо это разные вещи.

А с адреса 192.168.0.1 пинги возвращаются от 192.168.254.1 или .100?

Пинг на 254.1 неудачно, на 254.100 - удачно. Тоже самое и с узлом 0.30.

Модель роутера TL-WR1045ND. Пробовал отключать программный и аппаратный NAT - никаких изменений.

Возможно автор открыл icmp на WAN интерфейсе 192.168.0.128, но не на LAN 192.168.254.0/24, ибо это разные вещи.

Причины конфликта IP адресов Windows, WAN и LAN подсетей

Чаще всего это происходит в следующих ситуациях:

Еще одна частая проблема, когда функция DHCP не активна на сетевом адаптере. О ней будет отдельный разговор.

Где искать ошибку?

Прежде всего, надо проверить, какой диапазон адресов выделен для использования при работе DHCP сервера в настройках роутера. Если при организации сети ничего не менялось в конфигурации роутера по умолчанию, то IP роутера можно прочитать на днище устройства

Если же его адрес, а также логин и пароль были изменены, то надо их узнать у сисадмина, войти в админку и найти раздел, отвечающий за адрес самого роутера.

Теперь, когда мы знаем наш диапазон, идем в настройки протокола TCP/IP v.4 на компьютере

И смотрим наш адрес. У меня как раз указан неправильный, не из того диапазона, поэтому я задам для него, допустим, 192.168.0.159. Если же у вас все верно, адрес в том же диапазоне и не идентичен роутеровскому, а конфликт IP адресов в сети остается, значит какому-то компьютеру уже задан ваш адрес. Нужно просто поменять цифры в последнем окошке. Также не забудьте в качестве шлюза и DNS-сервера IP адрес самого роутера, чего не сделано на вышепредставленном скриншоте.

Теперь возвращаемся в админку маршрутизатора в раздел, отвечающий за DHCP-сервер.

Во-первых, активируем ручной режим.
Во-вторых, выбираем из выпадающего списка нужный нам компьютер по его ID или MAC адресу, и прописываем его не меняющийся IP, который ранее был нами указан в настройках протокола Интернета TCP/IP, как было показано выше.

Конфликт с другой системой

Для этого заходим в раздел с его IP, меняем его на 192.168.0.1 и сохраняем-перезапускаем.

Подключение к интернету по WAN-LAN

Наконец, последний случай, когда у вас нет никакой домашней или офисной локальной сети, компьютер напрямую подключен к интернету через порт WAN/LAN, а ошибка все равно есть и вы не можете к нему подключиться.

Видео

Помогите друзя чайнику.
На прошлой работе была сеть на 25 компов, на верхнем этаже стоял D-link dir-620 с адресом 192.168.0.1 в который приходил инет от провайдера, от него шли свитчи по этажу к пк.
От свитча на первый этаж шел кабель к еще одному D-linkу у которого был адрес 192.168.0.2 дсхп отключен и шлюзом прописан первый длинк. Все работало прекрасно в одной подсети.
Сейчас пришел на другую работу, тут две подсети, половина компов друг друга не видят. Решил сделать по той же схеме, что и раньше.
Но когда на втором роутере пытаюсь указать Wan 192.168.0.1 и лан 192.168.0.хх то роутер Tenda W311R+ ругается и не дает мне прописать Lan и Wan в одной подсети, заставля делать две разные подсети.
В чем прикол, и что делать?

Первый роутер, допустим, имеет адрес 192.168.0.1 и dhcp на нем пусть раздает адреса допустим с адреса 192.168.0.100. Второму роутеру допустим прописываем адрес 192.168.0.2 (dhcp на нем выключен и wan Connection Type = Disabled или Assign WAN Port to Switch, т.е. он работает простым коммутатором).

Я бы начал с вопроса для чего второй роутер?
Да и вообще можно было бы и схемку сети нарисовать

Who is the man who solves your problems you didn't know about, in a way that you don't understand?

Я бы начал с вопроса для чего второй роутер?
Да и вообще можно было бы и схемку сети нарисовать

Редакция не вступает в переписку с читателями.
Рукописи не возвращаются и не рецензируются.

Я бы начал с вопроса для чего второй роутер?
Да и вообще можно было бы и схемку сети нарисовать

Да второй роутер нужен чтобы, во второй половине здания вайфай ловил , так же к нему несколько ПК подключены, вместо коммутатора.
Я уже понял в чем затупил , втыкал в Ван порт сетку, а надо было в Лан. Просто не понимаю, зачем на 2 компов было делать две подсети, или просто тупо второй роутер воткнули и настроили отдельную подсесть для выхода в инет.а компы друг друга не видят, к принтерам не подключиться . Хочу одну сеть сделать, чтобы без маршрутов и всяких заморочек

192.168.0.1 - сомнительно, чтобы провайдер такие адреса раздавал, больше похоже на шлюз подсети 192.168.0.0/24 которую первый роутер создал.
Если в кратце, то второй роутер, который работает в качестве коммутатора настраивается следующим образом:
1. wan не используется
2. В LAN Settings (Настройки локальной сети) вписать адрес из подсети первого роутера (из свободных естественно, чтобы конфликтов не было), прописать маску, саррее всего 24-ю 255.255.255.0, отключить раздачу dhcp, dns
3. Настроить беспроводную сеть

192.168.0.1 - сомнительно, чтобы провайдер такие адреса раздавал, больше похоже на шлюз подсети 192.168.0.0/24 которую первый роутер создал.
Если в кратце, то второй роутер, который работает в качестве коммутатора настраивается следующим образом:
1. wan не используется
2. В LAN Settings (Настройки локальной сети) вписать адрес из подсети первого роутера (из свободных естественно, чтобы конфликтов не было), прописать маску, саррее всего 24-ю 255.255.255.0, отключить раздачу dhcp, dns
3. Настроить беспроводную сеть

Да так и делаю сейчас, вот только не могу пока с первым роутером разобраться, старый mikrotik, жесть там настройки, надо раздачу айпишников прописать что бы с сотки например начинались

что значит "старый" и "жесть там настройки"? 100 лет такие.

Who is the man who solves your problems you didn't know about, in a way that you don't understand?

что значит "старый" и "жесть там настройки"? 100 лет такие.

Специалисту необязательно уметь самому. Главное уметь учить других.

Редакция не вступает в переписку с читателями.
Рукописи не возвращаются и не рецензируются.

Не пойму, чего так народ микротов пугается? Для обычных целей имеется прекрасная первая вкладка - Quck Set. Если не надо vpn, vlan, хитрые маршруты делать и трафик по портам распределять с ограничениями - Quck Set все что нужно.
Конкретно про айпишники, выставляются настройки в поле Local Network: IP Address: 192.168.0.1 (адрес шлюза), в поле Netmask 255.255.255.0 (/24) маска подсети, ставится крыжик DHCP Server, в DHCP Server Range указывается диапазон адресов, например 192.168.0.10-192.168.0.254, ставится крыжик NAT.
Вот и вся настройка сети.
Единственно, если провайдер выдает "белый" IP, то не помешает почитать хоть вот это Защита WAN-интерфейса в Mikrotik

Клиенты получают неверные настройки (IP-адреса) по DHCP

Чтобы взаимодействовать с другими, каждому устройству в сети необходимо иметь четыре основные настройки на сетевом адаптере — IP-адрес, маску, шлюз по умолчанию и адреса DNS-серверов (хотя последнее на самом деле опционально). Есть два основных способа назначения сетевых настроек — статически (вручную) и динамически (автоматически по протоколу DHCP от DHCP-сервера).

Симптомы

Обычно всё начинается с жалоб на неработающий интернет или отсутствие доступа к локальным сетевым ресурсам. Иногда достаточно провести диагностику только на стороне клиента, но может понадобиться полная диагностика и со стороны сервера в том числе. Начнём с первой опции.

Диагностика на стороне клиента

Чтобы понять, что происходит, первым делом, конечно, следует проверить, подключён ли клиент физически к проводной или беспроводной сети. Если да, то самое время приступать к проверке сетевых настроек на устройстве клиента с помощью утилит ipconfig /all (в командной строке Windows), ifconfig или ip addr (в терминале Linux).

Вывод команд покажет текущий IP-адрес и другие настройки на сетевом адаптере (или всех адаптерах, если их несколько). При этом, если на сетевом адаптере нет корректного IP-адреса, возможных вариантов его настроек может быть немного.

Вариант 1. Текущий IP-адрес имеет вид 169.254.Х. Х

Скорее всего, на клиентской машине при этом установлена ОС Windows. Это значит, что клиенту действительно не удалось получить сетевые настройки, потому что DHCP-сервер не отвечал, и адрес был сгенерирован службой APIPA (Automatic Private IP Addressing) из диапазона 169.254.0.0 – 169.254.255.255. Если клиент — Linux-машина, адрес может принимать вид 0.0.0.0, либо отсутствовать в принципе.

Пожалуй, самое очевидное действие в такой ситуации — попытаться снова получить IP-адрес, отправив повторно DHCP-запрос, а заодно убедиться, что на устройстве запущен DHCP-клиент. Это можно сделать несколькими способами:

При выводе каких-либо ошибок и/или предупреждений нужно в первую очередь их устранить — например если DHCP-клиент не запущен, сперва его необходимо включить. После этого нужно снова проверить настройки. Если результат остался прежним, проверьте работоспособность сетевого драйвера и стека протоколов TCP/IP в целом. Проще всего это сделать с помощью команды ping 127.0.0.1 (так называемая проверка внутренней обратной петли). Если в результате выполнения команды ответ от собственного сетевого адаптера получен, можно считать диагностику на стороне клиента завершённой и переходить к диагностике со стороны DHCP-сервера.

Вариант 2. Текущий IP-адрес не из диапазона 169.254.0.0 – 169.254.255.255, но и не из того диапазона адресов, которые должен выдавать DHCP-сервер

Как известно, чудес не бывает. Если настройки, которые получает клиент, не от доверенного DHCP-сервера в сети, значит, их раздаёт кто-то другой. Тот, кто случайно или специально подключил к сети DHCP-сервер со своей конфигурацией. Возможно, это обычный Wi-Fi-роутер, к которому кабель по ошибке подключили через один из LAN-портов. Тогда ваша задача — найти недоверенный DHCP-сервер и предотвратить такие попытки в будущем.

Здесь нужно вспомнить, как работает DHCP-протокол. Клиент отправляет широковещательный запрос (DHCPDISCOVER), который получат все DHCP-серверы в сети и отправят в ответ свои предложения IP-адреса (DHCPOFFER). При этом клиент примет первое полученное предложение (DHCPOFFER), скорее всего, от ближайшего DHCP-сервера, а остальные отклонит.

Очевидно, что предложение от доверенного DHCP-сервера приходит позже, скорее всего, потому, что он дальше от клиента. Для последующей диагностики на устройстве клиента нужно установить анализатор сетевого трафика (Wireshark или tcpdump), запустить его, отфильтровав трафик по типу протокола DHCP или портам 67–68, и посмотреть в DHCP-ответах IP и MAC адрес DHCP-сервера, который их отправляет:

Дальше дело за малым. Во-первых, можно воспользоваться сервисом macvendors. com или аналогичным и по MAC-адресу определить производителя оборудования этого устройства. У Wireshark есть такая функция. Во-вторых, если есть управляемые коммутаторы в сети, найти по MAC, в какой порт какого коммутатора подключено это устройство. После нейтрализации недоверенного DHCP-сервера клиенту, скорее всего, удастся получить верные настройки. Для предотвращения таких инцидентов в будущем рекомендуется внедрить методы защиты от атак на DHCP на сетевом оборудовании.

Вариант 3. Текущий IP-адрес корректный, но доступа к интернету и другим сетевым ресурсам по-прежнему нет

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

Следует помнить, что DHCP-сервер может раздавать настройки выборочно, а сам клиент может выборочно их применять. Например, только IP-адрес, маску и шлюз. Это скорее исключение, но в таком случае адреса DNS придётся прописать руками. Гораздо хуже, если настройки адресов DNS-серверов от DHCP-сервера игнорируются просто потому, что их переопределяет стороннее ПО или неверные статические настройки. Такое тоже бывает.

Диагностика на стороне сервера

Итак, диагностика на стороне клиента показала, что проблем не обнаружено. Независимо от реализации DHCP-сервера, теперь необходимо пошагово проверить ряд предположений, начиная с самых простых и очевидных.

Запущен ли DHCP как сервис?

В зависимости от ОС, дистрибутива и реализации DHCP-сервера, проверить это можно по-разному. Если сервис остановлен и есть ошибки в конфигурационных файлах, то запустить его не удастся. Это первая отправная точка. Если сервис запущен, можно переходить к следующему шагу.

Приходят ли запросы от клиентов на DHCP-сервер?

Чтобы определить это, нужно снова запустить анализатор сетевого трафика. На этот раз на сервере. После запуска на сервере tcpdump, dhcpdump или Wireshark клиенту, у которого проблемы с получением адреса, необходимо попытаться получить его снова любым способом, описанным в начале статьи. Если DHCP-сервер работает в штатном режиме, то должны быть и запросы, и ответы. Но всё может быть иначе.

Предположим, что у нас есть по крайней мере один клиент, которому не удаётся получить настройки, и запрос от него точно должен был прийти на сервер. Если этого не произошло, очевидно, что клиент либо сам не отправляет запрос, либо запрос не доходит до сервера по разным причинам. Может, он блокируется на промежуточном сетевом оборудовании или в сети некорректно работает ретрансляция DHCP-запросов dhcp_relay.
Чтобы это проверить, можно в первом случае вернуться к диагностике на стороне клиента и проследить с помощью анализатора сетевого трафика, что клиент отправляет DHCP-запрос. Во втором — проверить настройки на промежуточном сетевом оборудовании.

Запрос(ы) есть, ответа(ов) нет?

Самая простая и очевидная причина в этом случае — закончился пул свободных адресов. Это легко проверить на самом DHCP-сервере по списку выделенных IP-адресов (leases). Если причина действительно в этом — задумайтесь: возможно, пришло время для увеличения пула пригодных для использования IP-адресов на сервере. Чтобы решить проблему прямо сейчас, можно почистить список существующих адресов, выданных в аренду клиентам, уменьшить время аренды и перезапустить сервис DHCP. Но быстрые решения помогают не всегда, а причин может быть гораздо больше. В таком случае придётся детально просматривать логи, а также последние изменения в конфигурации на сервере.

Обнаружен конфликт IP-адресов в Windows 7/8/10: методы решения

Обнаружен конфликт IP-адресов Windows

В этой сети уже есть компьютер с таким же IP-адресом. Обратитесь к системному администратору для разрешения этой проблемы. Дополнительные сведения см. в системном журнале Windows.

Наиболее часто этой ошибкой страдают пользователи, компьютеры которых напрямую подключены к маршрутизатору. Также напоминаем, что подобного рода проблематика не зависит от версии вашей операционной системы.

Ок, давайте об этом поподробней. Проблема ошибки «Обнаружен конфликт IP-адресов в Windows» заключается в том, что в вашей сети уже присутствует устройство с точно таким же IP-адресом, которое было дано компьютеру, т. е. один и тот же IP-адрес дался двум устройствам.

Почему же произошел такой сбой? Ну, когда вы создаете беспроводную точку подключения, то ваш роутер начинает автоматически присваивать различным устройствам с сети определенные IP-адреса с помощью DHCP-протокола. Так что за появлением сбоя может стоять ваш маршрутизатор, который, по какой-то причине, дал один и тот же IP-адрес двух устройствам в сети.

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

Несмотря на все вышесказанное, конфликт IP-адреса в сети не является в большинстве случаев серьезной проблемой и ее можно разрешить довольно быстро и безболезненно для пользователя. В этой статье мы собрали несколько методов по решению ошибки «Обнаружен конфликт IP-адресов в Windows», выполнение которых не должно составить для вас никакого труда.

Исправляем ошибку «Обнаружен конфликт IP-адресов в Windows»

Итак, для начала давайте просто попробуем выполнить с вами перезагрузку вашего компьютера, так как ошибки и сбои с операционной системой ни для кого не новость. Возможно, ошибка «Обнаружен конфликт IP-адресов в Windows» является просто небольшой неурядицей. Ну как, помогло? Если нет, то двигаемся дальше.

Далее вы можете попробовать выполнить перезапуск своего маршрутизатора. Возможно, тот дал вашему компьютеру уже выданные IP-адрес по ошибке. Простой перезапуск устройства может решить проблему. Для перезапуска роутера вам нужно отключить питание от него примерно где-то на полминуты, а затем снова включить его. Сделать это можно с помощью специальной кнопки на корпусе или же через отключения кабеля питания из специального разъема на задней части того же корпуса.

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

Выставление автоматического получения IP-адреса адреса DNS-сервера

Нажмите правой кнопкой мыши на иконке вашего сетевого подключения в Области уведомления Пуска и перейдите в «Центр управления сетями и общим доступом». Попав в указанное окно, нажмите на ссылку «Изменение параметров адаптера», находящееся в левой части окна.

Далее найдите свое сетевое подключение. Нажмите на него правой кнопкой мыши и выберите пункт «Свойства».

Заметка: Теперь вам нужно найти тот протокол Интернета, которые используется вашим Интернет-провайдером. В большинстве случаев используется устаревший Интернет протокол 4 версии. Однако, ваш провайдер может использовать и шестую версию. В показательных целях, мы будем использовать четвертую версию Интернет-протокола.

Выставление статического IP-адреса для сетевого подключения

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

Заметка: пока вы находитесь в настройках своего сетевого подключения, то вы также можете попробовать выставить для себя статические адреса DNS-серверов. Особенно, если у вас ранее наблюдались какие-то проблемы с выполнением входа на различные веб-ресурсы. Поставьте галочку напротив опции, позволяющей выставлять статические адреса для DNS, а затем пропишите 8.8.8.8. для предпочтительного и 8.8.4.4. для альтернативного сервера.

Что делать, если Android не удаётся получить IP-адрес сервера для доступа в интернет

Трудно сказать точно, почему эта ошибка возникает, но вот вам несколько хитростей, чтобы попытаться заставить ваше интернет-соединение работать снова.

Забудьте сеть

Перезапустите роутер

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

Переименуйте ваше Android-устройство

Мы не знаем знаем, почему это помогает, но многие пользователи утверждают, что это решает проблему. Процесс тоже прост, так что пробуйте.

Включите и выключите «Режим полета»

Это заставляет роутер перенастроить ваше соединение. Просто ненадолго включите Режим полета, а затем выключите его и попытайтесь снова подключиться к сети.

Используйте шифрование WPA2-PSK

Некоторые устройства не очень хорошо работают с определенными типами шифрования, включая AES и TKIP. Зайдите в настройки вашего роутера и переключитесь на WPA2-PSK.

Проверьте MAC-фильтр

При настройке Wi-Fi MAC-адреса часто используют для внесения в белый или черный список устройств, находящихся в сети. Это означает, что если ваше устройство отсутствует в белом или черном списке, оно не сможет подключиться. Решением будет либо отключить MAC-фильтр вашего роутера, либо удалить устройство из черного списка, либо добавить его в белый список.

Назначьте статический IP-адрес

Очистите кеш сервисов Google Play

Этот метод, кажется, используется во всех руководствах по устранению любых багов на Android, и это потому, что сервисов Google Play представляют собой большую часть софтверного наполнения вашего устройства. Перезапуск приложения с нуля может решить множество проблем.

Сбросьте данные

Если ничего не помогает, и проблема сохраняется в течение длительного периода времени, вы можете рассмотреть возможность сброса устройства до заводских настроек. Это удалит все данные на вашем смартфоне и вернет его к его заводскому состоянию. Обязательно сделайте резервную копию любых важных файлов, прежде чем продолжить.

Один из этих способов наверняка должен помочь вам подключиться к сети либо сразу, либо через некоторое время. Знаете какие-нибудь другие способы решения этой проблемы? Дайте нам знать о них в комментариях.

Делитесь своим мнением в комментариях под этим материалом и в нашем Telegram-чате.

Свободное общение и обсуждение материалов

Google Pixel 4a дебютировал в прошлом году, как более доступный вариант по сравнению с оригинальным телефоном. Сначала мы ждали этот аппарат во время Google I/O, но мероприятие было отложено из-за начавшейся пандемии. А позже стало понятно, что презентация и не планировалась, так как аппарат вышел только через несколько месяцев после предполагаемой даты презентации. В этом году мы уже начали получать новые слухи о выходе Pixel 5a на конференции разработчиков 2021. Поисковый гигант, скорее всего, проведет свою ежегодную конференцию в период с мая по июнь, но будут ли на ней представлены смартфоны, пока остается загадкой. Я бы предположил, что да, но давайте разберемся в этом более подробно. А заодно поймем, чего нам еще ждать от линейки Pixel в этом году.

Часто не самые опытные пользователи Android могут столкнуться с некоторыми проблемами, решение которых им не по силам. Часто это бывают какие-то мелочи, решение которых требует буквально пары тапов по экрану, но при этом не лежит на поверхности. Одной их таких проблем является нехватка свободного места. Бывает такое, что человек пользуется телефоном с большой памятью, но в какой-то момент при попытке скачать не самое крупное приложение, он сталкивается с неприятным предупреждением. Оно гласит, что в памяти нет места и приложение не может быть скачано. Паника и разочарование сменяют друг друга, а на самом деле надо всего лишь сделать несколько простых действий.

Конфигурация компьютера
Процессор: I7 10700
Материнская плата: Asus h470-plus
Память: Hyper 32 GB
HDD: Crucial ct1000
Видеокарта: Gigabyte GeForce rtx 260
Блок питания: Thermaltake smart 650 w
Монитор: Samsung U32J592UQU
Ноутбук/нетбук: Lenovo T420s
ОС: W10 x64

вот с этим не очень понятно "Перетыкаете провод из WAN в LAN" »

поднимаете правую руку.
тяните её к проводу, который подключён к WAN порту.
прикасаетесь к проводу.
Пальцами нажимаете на "замок" в проводе.
Отсоединяете провод от порта WAN. (оттыкаете)
Провод остаётся в руке.
Перемещаете руку с проводом к любому порту LAN.
Подключаете провод в порт LAN. (втыкаете)
Убираете руку.

-------
Вежливый клиент всегда прав!

exo, все равно локалку не видит,все делал как ты написал

Конфигурация компьютера
Процессор: I7 10700
Материнская плата: Asus h470-plus
Память: Hyper 32 GB
HDD: Crucial ct1000
Видеокарта: Gigabyte GeForce rtx 260
Блок питания: Thermaltake smart 650 w
Монитор: Samsung U32J592UQU
Ноутбук/нетбук: Lenovo T420s
ОС: W10 x64

-------
Вежливый клиент всегда прав!

exo, в настройках роутера в Список клиентов DHCP видны оба PC но локалку не видит

mishastepanov@vk, вообще-то, уважаемый, если человек приходит за помощью, то он внимательно выполняет указания людей, изъявивших желание помогать. В противном случае этот человек отбивает охоту предоставлять помощь.

Нарисуйте схему вашей сети. А то запутаете себя и нас.

-------
- Пал Андреич, Вы шпион?
- Видишь ли, Юра.

С компа
Microsoft Windows XP [Версия 5.1.2600]
(С) Корпорация Майкрософт, 1985-2001.

C:\Documents and Settings\Миша>ipconfig/all

Настройка протокола IP для Windows

Имя компьютера . . . . . . . . . : PC1
Основной DNS-суффикс . . . . . . :
Тип узла. . . . . . . . . . . . . : неизвестный
IP-маршрутизация включена . . . . : да
WINS-прокси включен . . . . . . . : да

Подключение по локальной сети 6 - Ethernet адаптер:

Подключение по локальной сети - Ethernet адаптер:

DNS-суффикс этого подключения . . :
Описание . . . . . . . . . . . . : Realtek RTL8168/8111 PCI-E Gigabit E
thernet NIC
Физический адрес. . . . . . . . . : 00-19-DB-CC-EC-EE
Dhcp включен. . . . . . . . . . . : да
Автонастройка включена . . . . . : да
IP-адрес . . . . . . . . . . . . : 192.168.1.2
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз . . . . . . . . . . : 192.168.1.10
DHCP-сервер . . . . . . . . . . . : 192.168.1.10
DNS-серверы . . . . . . . . . . . : 192.168.1.10
Аренда получена . . . . . . . . . : 12 декабря 2012 г. 16:13:32
Аренда истекает . . . . . . . . . : 13 декабря 2012 г. 16:13:32

Настройка протокола IP для Windows

Имя компьютера . . . . . . . . . : PC2
Основной DNS-суффикс . . . . . . :
Тип узла. . . . . . . . . . . . . : Смешанный
IP-маршрутизация включена . . . . : Нет
WINS-прокси включен . . . . . . . : Нет

Ethernet adapter Сетевое подключение Bluetooth 3:

Адаптер беспроводной локальной сети Беспроводное сетевое соединение:

DNS-серверы. . . . . . . . . . . : 192.168.0.1
NetBios через TCP/IP. . . . . . . . : Включен

Ethernet adapter Подключение по локальной сети:

Состояние среды. . . . . . . . : Среда передачи недоступна.
DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : Адаптер Microsoft ISATAP
Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да

Туннельный адаптер Reusable ISATAP Interface 48>:

Туннельный адаптер 6TO4 Adapter:

Состояние среды. . . . . . . . : Среда передачи недоступна.
DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : Адаптер Microsoft 6to4
Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да

Туннельный адаптер Подключение по локальной сети* 5:

DNS-суффикс подключения . . . . . :
Описание. . . . . . . . . . . . . : Туннельный адаптер Microsoft Teredo
Физический адрес. . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP включен. . . . . . . . . . . : Нет
Автонастройка включена. . . . . . : Да
IPv6-адрес. . . . . . . . . . . . : 2001:0:5ef5:79fd:2c8c:2041:3f57:ff9a(Осно
вной)
Локальный IPv6-адрес канала . . . : fe80::2c8c:2041:3f57:ff9a%25(Основной)
Основной шлюз. . . . . . . . . : ::
NetBios через TCP/IP. . . . . . . . : Отключен

Читайте также:

Ip адрес не указан в одной подсети с lan ip адресом укажите другое значение

Комментарии

Причины конфликта IP адресов Windows, WAN и LAN подсетей

Где искать ошибку?

Конфликт с другой системой

Подключение к интернету по WAN-LAN

Видео

Клиенты получают неверные настройки (IP-адреса) по DHCP

Симптомы

Диагностика на стороне клиента

Вариант 1. Текущий IP-адрес имеет вид 169.254.Х. Х

Вариант 2. Текущий IP-адрес не из диапазона 169.254.0.0 – 169.254.255.255, но и не из того диапазона адресов, которые должен выдавать DHCP-сервер

Вариант 3. Текущий IP-адрес корректный, но доступа к интернету и другим сетевым ресурсам по-прежнему нет

Диагностика на стороне сервера

Запущен ли DHCP как сервис?

Приходят ли запросы от клиентов на DHCP-сервер?

Запрос(ы) есть, ответа(ов) нет?

Обнаружен конфликт IP-адресов в Windows 7/8/10: методы решения

Исправляем ошибку «Обнаружен конфликт IP-адресов в Windows»

Выставление автоматического получения IP-адреса адреса DNS-сервера

Выставление статического IP-адреса для сетевого подключения

Что делать, если Android не удаётся получить IP-адрес сервера для доступа в интернет

Забудьте сеть

Перезапустите роутер

Переименуйте ваше Android-устройство

Включите и выключите «Режим полета»

Используйте шифрование WPA2-PSK

Проверьте MAC-фильтр

Назначьте статический IP-адрес

Очистите кеш сервисов Google Play

Сбросьте данные