none
При отключении шлюза падает вся сеть RRS feed

  • Общие обсуждения

  • Здравствуйте, у нас локальная сеть с доменом, и шлюз на WS2008R2 (2 сетевые 1 в интернет, другая в локальную сеть), при отключении шлюза исчезает доступ к файловым серверам, sql серверам, включая RDP и пинг.

    1. Как сделать чтоб при выключении шлюза, клиенты этого не замечали, а то  в случае перезагрузки шлюза все начинают звонить, почему все не работает.

    2. Как построить небольшую сеть (win7) 4-10 ПК, без домена и шлюза, НО  чтобы пользователи могли обмениваться информацией по сети, пользоваться общим принтером и т.д (отключение брандмауэра, правильные настройки дополнительных параметров общего доступа  не помогают)

    15 ноября 2013 г. 0:51

Все ответы

  • Я подозреваю что у вас там живет сервис который разрешает имена, например DNS, а разрешение имен другими способами (броадкастом например) запрещено. Проверьте пингом по имени (должно не работать) или адресу (должно работать).

    1. Когда выясним в чем дело то будем решать что делать.

    2. Все сети так и работают пока администратор не изменит настройки.


    This posting is provided "AS IS" with no warranties, and confers no rights.

    15 ноября 2013 г. 2:15
    Модератор
  • 1. только сегодня с утра (пока ни кого не было на работе смог провести эксперимент), запустил пинг -t файлового сервера по ip и по имени, подключился по рдп, пинги шли успешно. Из сервера шлюза выдернул провод который вел в локальную сеть таким образом его как бы выключил, и все пинги пропали с рдп выбило, и не по имени ни по ip на сервер попасть невозможно.

    2. То есть если взять чисто установленные windows и сделать из них сеть то она будет работать?. если да то нет, потому что так делали, там по умолчанию запрещен гостевой доступ, центре управления сетями отключен сетевой доступ, и если просто открыть доступ к папке (на чистой windows при настроенных ip) то никто не сможет к ней получить доступ, у Меня не получалось.

    18 ноября 2013 г. 22:10
  • Еще есть неведомая проблема, некоторые компьютеры локальной сети не пингуются ни по имени, ни по адресу, но пингуются с ключем -6,  и к ним можно попасть через обозреватель по имени (наверно тоже по ipv6), хотя я не настраивал ipv6, скорее напротив его избегал. и это не настройки конкретных компьютеров, т.к. раньше не было таких проблем.
    18 ноября 2013 г. 23:59
  • Нарисуйте схему ващей сети. Укажите узлы с которых пинговали и которые пинговали.

    Да, будет работать. Почти все мелкие сети так были устроеные несколько лет назад пока не появились дешевые раутеры с DHCP серверами. 

    В новых ОС сеть автоматически становится приватной если не прописан default gateway. Его наличие не требуется но он должен быть прописан.


    This posting is provided "AS IS" with no warranties, and confers no rights.

    19 ноября 2013 г. 2:11
    Модератор
  •  Его наличие не требуется но он должен быть прописан.
    то есть пишем любой адрес и все работает?
    19 ноября 2013 г. 3:26
  • Вдергиваю шнур 2 из gate, и со станции User1: ping 192.168.0.8, ping Escort, так же пробую зайти на escort через проводник и рдп. Ничего не получается.

    На ad1 зайти получается.

    Если воткнуть шнур обратно все заработает. НО если набрать команду ping user2, либо ping 192.168.1.14, то скажет заданный узел недоступен, а если написать ping 192.168.1.16 -6 то покажет ответы с ipv6 адресом.

    19 ноября 2013 г. 4:07
  • А зачем у вас такая большая маска подсети? Похоже на проблемы маршрутизации, у вас все находится в одном бродкаст-домене с /16 маской, а из сети с рабочими станциями до контроллеров вы походу идете через шлюз. Хотя если все как на картинке - то должно работать, перепроверьте маски на всякий случай.
    19 ноября 2013 г. 5:34
  • Для компьютера в домене, со шлюзом по умолчанию, сеть автоматически определяется как "доменная" (рабочая).

    При отсутствии шлюза по умолчанию, сеть автоматически определяется как "общественная" (публичная).

    Как результат, действующие наборы правил встроенного файрвола существенно разные. Смотрите туда.


    S.A.

    19 ноября 2013 г. 5:50
  • Там еще адреса есть выше 192.168.1.0, на серверах маски вручную на клиентах dhcp.
    19 ноября 2013 г. 7:01
  • А брандмауэр отключен на проблемном ПК
    19 ноября 2013 г. 7:02
  • Если на проблем ПК убрать основной шлюз пинги до файлового сервера есть?

    Отключите брэндмауэр и на сервере тоже
    19 ноября 2013 г. 7:03
  • Проблемный пк и есть сервер
    19 ноября 2013 г. 7:24
  • )))) запутка началась

    С компьютер user1 есть пинги до файлового сервера, если выдергиваете провод 2 к gate пинги пропадают, так?

    19 ноября 2013 г. 7:28
  • А если с компьютера user1 убрать шлюз по умолчанию пинги идут?
    19 ноября 2013 г. 7:32
  • если убрать шлюз идут, если убрать шлюз и выдернуть шнур 2, не идут.
    19 ноября 2013 г. 7:36
  • Похоже на проблемы коммутации на DGS-1024D. Если при убранном шлюзе пинги ходят, то проверяйте канальный уровень.
    19 ноября 2013 г. 7:39
  • Похоже на проблемы коммутации на DGS-1024D. Если при убранном шлюзе пинги ходят, то проверяйте канальный уровень.

    а почему такой вывод можно подробней или ссылку, хочу разобраться до предела.
    19 ноября 2013 г. 10:55
  • Ну ссылку не дам конечно, но про вывод скажу:

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

    По каким-то причинам у вас разные участки сети не получают фрэйм c ff arp, когда вы вытаскиваете провод из gate 2. Я считаю, что эта причина на канальном уровне и нужно проверять разводку проводов, но мнение только мое :)

    19 ноября 2013 г. 11:48
  • Что сеть работает без шлюза мне нравится, но мне не нравится что если убрать шлюз то интернета не будет, то есть такой вариант в принципе не рассматривается.

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

    Если поставить шлюз то все пакеты будут адресованы ему?

    Ведь когда я пишу пинг с user1 на user2, на которых прописан шлюз gate то не работает, а если у них убрать шлюз то все будет отлично.

    19 ноября 2013 г. 22:33
  • И при всем этом остается основная проблема, сервер escort блокируется,без шлюза, переходя в общественные сети, но брандмауэр выключен.
    19 ноября 2013 г. 22:39
  • Тип сети не зависит от физического наличия гейтвея, только от того прописан он или нет. При выдергивании кабеля прописанный гейтвей не меняется, стало быть это скорее всего не при чем.

    Я бы предположнил что по каким то причинам все пакеты идут через гейтвей - чего быть не должно в одном и том же сегменте сети.

    Для проверки выполните tracetr так же как делали пинг. Если в трейсе будет шлюз то значит все идет через него.

    Почему такое может быть? Скажем если на клиентах с адресами 192.168.1.х по каким то причинам стоит маска 255.255.255.0 (а не 255.255.0.0), то с точки зрения клиента сервер с адресом 192.168.0.х находится в другом сегменте и, стало быть, надо посылать пакет на адрес гейтвея. 



    This posting is provided "AS IS" with no warranties, and confers no rights.

    20 ноября 2013 г. 2:25
    Модератор
  • tracert до машины, до которой не проходит пинг пишет превышен интервал ожидания запросов, много раз, столько сколько указано прыжков, до другой машины, с которой проблем нет там сразу говорит её адрес в 1 прыжок.

    "Почему такое может быть? Скажем если на клиентах с адресами 192.168.1.х...."

    ipconfig /all говорит что 1 маска, просто проблема в том что если убрать шлюз то пинг есть, если вернуть  то нет.

    может ли клиент по каким то причинам все запросы отправлять через шлюз кроме маски.

    20 ноября 2013 г. 5:40
  • Очевидно может, иначе проблемы бы не возникало. :)

    А вот почему это происходит загадка. Возможно действительно что то хитрое на свичах, скорее 3052 так как он хитрый. Второй свич я думаю не при чем. 

    Попробуйте на двух компьютерах  подключенных к 3052 прописать маску 255.255.255.0 и посмотрите что будет. Может на свиче какие нибудь виртуальные сабнеты сконфигурированы или что то в этом роде.


    This posting is provided "AS IS" with no warranties, and confers no rights.

    21 ноября 2013 г. 7:21
    Модератор
  • Попробовал, не помогло (превышен интервал ожидания запроса), а хитрых настроек там не может быть (если только не по умолчанию) потому как нам эту сеть сдавали монтажники а мы ничего не настраивали. И ведь раньше все работало (не была запущена служба маршрутизация и удаленный доступ) а стояла галочка в свойствах подключения "разрешить другим пользователям использовать..."
    21 ноября 2013 г. 23:18
  • Стыдно признать, но действительно на 2-х проблемных серверах была маска 255.255.255.0, поэтому все не работало.))

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

    5 декабря 2013 г. 1:24