Плавающая проблема, пропадает доступ к некоторым ресурсам по шифрованным протоколам
 

Доброе время суток. Имеется сеть топологии "звезда", соединенная несколькими свитчами:
1. Имеется основной свитч, к которому подключены 3 дополнительных свитча, серверы, и часть клиентских компьютеров
2. К 3-м дополнительным свитчам подключены клиентские компьютеры.

. Имеется интернет-сервер, выступающий в роли шлюза, на сервере 2 сетевухи, 1 подключена к локальной сети, вторая подключена к интернету.
Имеется странная плавающая проблема: временами на всех компьютерах офиса отсутствует доступ к ресурсам по шифрованному протоколу, а именно:
1. Имеется корпоративный почтовый сервер, расположенный вне офиса, к нему пользователи получают доступ через веб-обозреватель по https - доступа нет: Internet Explorer не может отобразить страницу
2. Имеется сервер, на котором хранятся некоторые данные организации, к которым пользователи получают доступ через FTP-клиента, трафик шифруется с помощью FTP через TLS (неявный) - доступа так же нет, при подключении происходит обрыв на "Соединение установлено, инициализация TLS"
3. В офисе широко используется TeamViewer, он так же не работает - "Разрешены подключения только по локальной сети".
При этом, в момент проблемы:
1. Сервера на которых расположены почта и FTP-сервер, доступны - идет пинг, могу зайти по удаленному рабочему столу, более того, к ним можно подключиться без шифрованного протокола: к почтовому серверу по http, к FTP-серверу по простому протоколу FTP
2. С самого интернет-сервера возможно подключиться ко всем 3-м вышеуказанным службам, с использованием шифрованного протокола
3. Другие ресурсы, так же использующие шифрованные протоколы, доступны (mail.ru, google.com)
4. Перезагрузка модема Интернет-провайдера не решает проблему, так же пробовал в момент проблемы отключать интернет-сервер от локальной сети, подключать вместо него простой шлюз TP-Link, подключал шлюз к модему провайдера, сетевухе шлюза локальной сети назначал адрес интернет-сервера локальной сети - проблемы не было, подключаю интернет-сервер в локальную сеть обратно - проблема восстанавливается (т.е. проблема не в модеме)
5. Перезагрузка интернет-сервера так же не решает проблему, проблему решает отключение сервера, и подключение его в сеть не сразу, а минут через 10.

Что делал для решения проблемы:
1. В момент проблемы, с одного из компьютеров пробовал удалить антивирус - проблема осталась, т.е. причина не в нем
2. В момент проблемы, пробовал последовательно отключать отключать от основного свитча 3 дополнительных, затем от основного свитча последовательно отключал компьютеры, после каждого отключения ждал 3 минуты. Т.е. подозревал глючное устройство в сети, котором может создавать проблему. Конечный результат был: к основному свитчу были подключены только интернет-сервер, сервер-КД, и еще 1 сервер БД, с которого проверял осталась ли проблема - проблема осталась... Т.е. вариант с глючным устройством, которое таким "элегантным" способом ложит сеть, пока не рассматриваю
3. Заменил интернет-сервер - взял другой сервер, установил на него чистую ОС Windows Server 2008R2, все обновления, антивирус пока не ставил для чистоты эксперимента, службы маршрутизации, некоторые рабочие программы (прокси сервер, который счас используется только для перенаправления портов из интернета в локальную сеть, FTP server Filezilla, Kaspersky Security Center)
- После все этого сегодня проблема повторилась....
Что сделал сейчас
1. Заменил основной свитч
2. На сетевой карте интернет-сервера отключил параметры:
IPv4: загрузка большой отправки… (дальше не получается прочесть, окно заканчивается)
IPv4: разгрузка контрольной суммы

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

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

Я правильно понимаю, что функции шлюза реализуются встроенными средствами Win Server 2008R2?

И еще. Что это за прокси-сервер, который используется для перенаправления портов? До переустановки серверной ОС, он тоже стоял?

Цитата IT Shepherd:
__sa__nya, судя из описания, у меня сложилось впечатление, что проблема где-то на шлюзе. В логах системы что-то есть, что указывало бы на проблему? »

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

Цитата IT Shepherd:
Я правильно понимаю, что функции шлюза реализуются встроенными средствами Win Server 2008R2? »

- Да

Цитата IT Shepherd:
И еще. Что это за прокси-сервер, который используется для перенаправления портов? До переустановки серверной ОС, он тоже стоял? »

UserGate 2.8 до переустановки тоже был . Использую только потому, что средствами ОС перенаправление сделать не удается. Пробовал в момент проблемы UG выключать - проблема не уходит

__sa__nya, очевидно, проблема в сервере. Поподробнее, что и как настраивали, цель использования usergate, прокси и т.д.

Lonely_Mouse,
1. Установил ОС, драйвера на нее, все последние обновления. Сделал настройки сетевух (IP-адреса). Установил UAC на самый верхний уровень безопасности
2. Установил Kaspersky Security Center, настроил (восстановил архив с настройками), создал для нее необходимые общие папки
3. Установил FileZilla FTP сервер, импортировал настройки, создал необходимые общие папки
4. Установил компонент RRAS, настроил в качестве VPN-сервера, шлюза, маршрутизатора 2-х сетей (локальной и интернет).
5. Установил UserGate 2.8, перенес файл настроек из старой ОС
- Все.

Цитата Lonely_Mouse:
цель использования usergate, прокси и т.д. »


- Об этом писал в посте выше:


Цитата __sa__nya:
UserGate 2.8 до переустановки тоже был . Использую только потому, что средствами ОС перенаправление сделать не удается. »

__sa__nya, опишите что и куда перенаправляете, как себя ведет без касперского и ug.

Lonely_Mouse, UG перенаправляет запросы поступающие на внешнюю сетевуху, на определенные службы в локальной сети:
1. Службы удаленных рабочих столов некоторых компьютеров, к которым нужен доступ из интернета "напрямую"
2. Аналогично, службы различных веб-серверов в локальной сети.
Более подробно на скриншоте ниже



Цитата Lonely_Mouse:
как себя ведет без касперского и ug. »

Как писал при создании темы - в данное время никакого антивируса не установлено. При возникновении проблемы, при выключении UG проблема не уходит.

__sa__nya, догадываюсь в чем проблема. Опишите подсети.

Lonely_Mouse,
2 подсети
1. 192.168.2.0 , маска 255.255.252.0 это основная сеть, в ней находятся все клиентские компьютеры
2. 192.168.1.0, маска 255.255.252.0 в этой сети находятся серверы (4 шт), которые по причине "геморойности" смены их адреса не были переведены в новую сеть.

__sa__nya, на роутере который в инет смотрит прописаны маршруты до этих подсетей с указанием в качестве шлюза сервер?

не понял вопроса. Во вложении выполнение команды route print на интернет-сервере, он же является шлюзом. Чтобы увидеть информацию на русском - в блокноте выберите шрифт "Terminal"

__sa__nya, файлик сейчас посмотреть не могу, но я что-то не понял по поводу двух подсетей. Маска 255.255.252.0 определяет подсеть с диапазоном адресов 192.168.0.1-192.168.3.255. Где здесь две подсети?9

IT Shepherd,
немного неправильно выразился, да. Логически подсеть одна. Я имел ввиду что в сети используются компьютеры с адресами из пространства 192.168.1.0 и 192.168.2.0 . Эти пространства и "обозвал" подсетями.
PS, блин, вот счас проблема возникла. Перезагрузка сервера не решает проблему....

Итак, сегодня 2 перезагрузки, отключение сетевых карт на сервере (смотрящей в локалку и интернет) проблему не решили. Решило проблему только отключение сервера на 5 минут, вместе с модемом.
Блин, как говорится, КАРАУЛ!

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

IT Shepherd, IT Shepherd, никаких отличий.
1. https://mail.ru - клиент - интернет-сервер - mail.ru
2. https://mymail.mydomain.kz - клиент - интернет-сервер - mymail.mydomain.kz
3. FTP (через TLS): клиент-интернет-сервер - FTP-сервер
4. TeamViewer - клиент-интернет-сервер- TeamViewer сервер

Для корп. почты используется 443-й порт. Все соединения ходят через NAT на интернет-сервере.

Ниже скриншот соответствующих трассировок, 1 - корп. почта, 2 - mail.ru, 3 - FTP, 4 - TeamViewer:
Причем, повторюсь - соединения для корп почты и FTP, если в момент проблемы настроить почту через http и FTP через ftp соответственно - т.е. без шифрования, работают...

IT Shepherd, , о каких маршрутах писал LonelyMouse в 10-м посте?

Во вложении прикрепил route print когда проблемы нет, заметил что все идентично, за исключением последних 2-х строк, они поменяны местами с route print который выкладывал в посте 11. - В тот момент как раз была проблема.

__sa__nya, я подумал, что за сервером роутер стоит. Нат настраивали так? Что показывает show mapping? Брандмауэр отключать пробовали?

- аналогично, на 6-м шаге выбирал "Особая конфигурация" и проставил NAT, VPN, маршрутизация ЛВС - в моей сетке нужно так.
- Вы об этом? -

- или какую-то команду нужно выполнить и вам выводимые данные скинуть?

__sa__nya, об этом. Только нужен момент, когда на 80 порт ходит и на 443. Может фильтры настроены или брандмауэр не пропускает?

Lonely_Mouse, Скриншот ниже, на момент скриншота проблемы не было. Когда будет, попробую сделать, но, по проблемным службам сопоставлений не будет, т.к. в этом и проблема, что подключиться не удается. Никакие фильры или брандмауэр подключение не блокируют. Например, в момент проблемы telnet'ом проверял порт, например почты - порт открыт.

__sa__nya, днс гугловский используется? Во время проблемы скиньте arp -a с клиентской машины.

Lonely_Mouse, нет, ДНС используется КД, он, в свою очередь использует ДНС держателя нашей зоны - это интернет-сервер. Но проблема не в ДНС, т.к. в момент проблемы, подключиться нельзя к почте ни по IP ни по ДНС-имени. Подключение по FTP выполняется по IP - так же в момент проблемы подключиться не удается.

__sa__nya, вы пробовали использовать debug-лог RRAS для идентификации проблемы?

IT Shepherd, нет, попробую в момент проблемы глянуть. Если ничего не пойму, скину вложением в тему.
Только непонятно, какой журнал смотреть. Установил в параметрах RRAS вести журнал всех событий, включая сведения для отладки, открыл папку %windir%\tracing - а там пустые файлы, файлы с расширением bin не содержат читабельной информации, файл RASPLAP.log содержит так же непонятную информацию:

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

IT Shepherd, гляньте пожалуйста мой пост выше.

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

Давайте пока попробуем глянуть сетевым монитором.

Доброе время суток. Сегодня, 08.07.15, в 07:30 по Москве проблема повторилась. Интересно то, что после прошлого повтора проблемы, я перевел всех пользователей на работу с нашим FTP-ресурсом без использования шифрованного протокола - т.е. по обычному FTP-протоколу. У меня были мысли, что большой объем шифрованного трафика "что-нибудь где-нибудь ломает" и получается проблема. НО, сегодня в момент проблемы, не было доступа к корпоративной почте, TeamViewer'у и FTP - ресурсу, без использования шифрованного протокола. ПРоблема опять решилась выключением сервера на 5 минут. Собрал логи сетевым монитором в момент проблемы с клиента и интернет-сервера, сделав фильтр по адресу назначения - 188.40.77.142 - это наш корпоративный почтовый сервер.
Файлы: залью чуть позже
Пробовал их смотреть, анализировать - ничего не понятно.
Может у кого есть мысли как найти причину проблемы?

__sa__nya, я конечно все понимаю, но зачем пароли от фтп выкладывать? :) Сервер ip динамически получает?

Lonely_Mouse, можете в личку отписать, где какой пароль "просочился" ? - Вроде в момент проблемы при сборе данных монитором по FTP не подключался....
У сервера IP статический.

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

Lonely_Mouse, по установке Flow Control и Task Offload.
- На внешней сетевухе таких параметров нет вообще, на внутренней есть только "Flow Control", его выключил. Слежу за полетом.

__sa__nya, беглый анализ лога сервера показал, что ступор происходит на прикладном уровне сетевой модели TCP\IP. Если говорить конкретно, то не происходит SSL\TLS рукопожатия. Я рассмотрел работу с почтовым сервером клиента 2.66.

1. Клиент и почтовый сервер проходят TCP рукопожатие и устанавливают TCP соединение.
2. Клиент отправляет сообщение Client Hello как первоначальный шаг в процедуре SSL\TLS рукопожатия. Видно, что данный пакет уходит с "внешней" карты шлюза.
3. ..... а в ответ - тишина. Почтовый сервер должен ответить сообщениями Server Hello, Certificate и т.д., но не делает этого.
4. Клиент повторяет запрос Client Hello до тех пор, пока не сбрасывает TCP соединение.
5. Затем устанавливает с сервером TCP соединение заново, пройдя процедуру рукопожатия и все пошло по кругу.

На основании этого я делаю вывод, что что-то не так с самим сервером. Это не ошибка конфигурации или сертификата, в этом бы случае сервер отвечал ошибкой, а не молчал. Можно предположить, что пакеты теряются где-то по дороге, но в таком случае трудно объяснить почему с завидным постоянством устанавливается TCP соединение с сервером.

Конечно, мое предположение о проблеме на стороне сервера не объясняет проблему с TeamViewer'ом или FTP, но я не видел сетевой лог работы с ними.

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

IT Shepherd, проблема не с почтовым сервером, т.к.:
1. В момент проблемы к почтовому серверу можно подключаться без проблем с интернет-сервера
2. Если в момент проблемы я быстро меняю для офиса выход в интернет вместо интернет-сервера на шлюз (т.е. к модему подключаю шлюз, например Zyxel Keenetik Omni, которому назначаю адрес локальной сети такой же как у сервера, шлюз подключаю к интернету, сервер от локалки отключаю) - проблема сразу уходит. Подключаю интернет-сервер обратно - проблема появляется
3. В момент проблемы к почтовому серверу можно без проблем подключиться с любой другой точки вне нашего офиса
4. В момент проблемы в офисе, к почтовому серверу можно подключиться не по шифрованному протоколу.

IT Shepherd, После того как я изменил подключение к FTP с шифрованного канала на нешифрованный, и проблема повторилась, у меня создалось впечатление, что на интернет-сервере (в операционке, или где-то в оборудовании) есть какие-то рамки, ограничения что-ли, и вот когда они каким-то образом достигаются, происходит проблема, т.к. теперь видно что проблема не только в шифрованных соединениях, если бы так было, то в момент проблемы доступ к FTP был, а его нет.
Что думаете?

__sa__nya, вы можете вспомнить, после чего или при каких обстоятельствах возникла эта проблема?

Возможно, но возникает вопрос: Почему эти "рамки" действуют только на определенные соединения? Тем более, как я написал, TCP соединение устанавливается без проблем, проблема возникает на прикладном уровне. К тому же, если верить логам, запрос на установку безопасного соединения уходит с внешней карты шлюза.
Пока для меня это не понятно, попробую найти время, чтобы посмотреть логи более детально.

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

И еще, я бы попробовал заменить карту Realtek RTL8139/810x Family Fast Ethernet на что-то другое.

IT Shepherd, первый раз эта проблема возникла после того как сменили Интернет-провайдера для основного интернет-канала+ начали выходить в интернет вместо шлюза через имеющийся интернет-сервер.
Было раньше:
1. 2 интернет-канала.
2. 1 интернет-Канал подключен через ADSL-модем к интернет-серверу, сервер является держателем зоны для ДНС-имени, FTP-сервером, так же являлся шлюзом для выхода в интернет для тех клиентов в сети, которым не нужна была высокая исходящая скорость.
3. 2 интернет-Канал подключен через интернет-шлюз Zyxel Keenetic Omni к более быстрому интернет-каналу, который офис использовал для выхода в интернет.
4. каналы подавали 2 разных провайдера
5. Провайдер подающий канал по DSL, смог подать канал по оптике, в итоге что имеем сейчас:
- от 2 интернет-канала отказались, убрали шлюз Zyxel Keenetic Omni
- 1 интернет-канал провайдер заменил на оптику, в офис заходит оптоволокно, стоит модем провайдера, к модему подключен интернет-сервер, сейчас весь офис выходит в интернет через него.
6. Примерно через пару недель после "переезда" на новый интернет-канал началась данная проблема.

Сначала грешил на Интернет-провайдера или на его модем для оптоволокна, но, рассудив логически, провайдера отбросил, т.к.
1. В момент проблемы с самого интернет-сервера можно получить доступ к ресурсам, к которым не имеют доступа клиенты локальной сети
2. В момент проблемы отключение модема провайдера на 3 минуты, перезагрузка модема не решают проблему, решает только выключение интернет-сервера
3. В момент проблемы подключение вместо интернет-сервера интернет-шлюза решает проблему.

- тоже думал об этом, думаю потому что эти "рамки" действуют на определенное количество соединений к одному целевому адресу. Т.е, например, весь офис - 40 компов, одновременно не работает с сайтом mail.ru, kaspersky.ru и т.д., но одновременно работает с FTP, корпоративной почтой, причем интенсивно, и вот эта интенсивность может что-то где-то "ломает". Может как-то так.

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

IT Shepherd, и еще:
1. - можете написать номера строк в трафике, хочу глянуть эти моменты, чтобы понять для себя о чем речь.
- вот ссылка на захват трафика по почте с клиента 192.168.2.48 на сервер 188.40.77.142, когда проблемы нет (зашел на стартовую страницу почтовика), выполнил вход в систему, проверил почту). Я просто почти не имею опыта с сетевым монитором, в отличие от вас, может сравнение логов в момент проблемы и когда проблемы нет, могут дать какие-то мысли...

PS: у меня уже была мысль опять сделать выход в интернет через шлюз Zyxel Keenetic Omni, а с него просто подключения по нужным портам перенаправлять на интернет-сервер (DNS, FTP, и еще около 15 важных подключений к службам локальной сети), но столкнулся с проблемой: Zyxel Keenetic Omni не перенаправляет соединения по нужным мне портам...

В логе клиента (2.48) видно, что он не может установить SSL-соединение с хостом go.trouter.io
Насколько я понял, этот хост каким-то образом связан с почтой от Microsoft. Не думаю, что все пользователи также одновременно работают с этой почтой.

Попробуйте pfSense в качестве шлюза. Это не займет много времени разобраться с базовой настройкой.

- это в логе в момент проблемы или в логе когда проблемы нет?
Пока не могу рассмотреть данный вариант.
Мне бы решить причину моей проблемы в моей имеющейся инфраструктуре.

В момент проблемы. Вы разве выкладывали логи в момент когда проблемы нет?

- мой 37-й пост когда проблемы нет, с интернет-сервера.

Это видимо редактирование, я его пропустил. Я этот файл еще не скачивал. Номера фреймов напишу уже не сегодня. :)

__sa__nya, глянул новый лог. Сразу два вопроса:

1. На шлюзе какой-то файрвол стоит для защиты?
2. DNS-сервер слушает и на внешней карточке запросы?

Просто строки следующего вида мне ну совсем не нравятся:

Некий внешний IP -> Внешняя карта шлюза: DNS запрос на разрешение имени apwrwnsrwvct. www. 9azz.com

И ваш сервер пытается разрешить имя вначале через DNS Гугла, потом через еще один DNS.

- Стандартный брандмауэр Windows
Да, он ведь является первичным ДНС-сервером для нашей зоны
- Просто к нему отправили запрос, он разрешает его через ДНС Гугла, т.к. в своей БД ДНС даных по запросу нет. Отключить ДНС для внешней сети не могу, т.к. перестанет работать нормально наша ДНС-зона. Но по-моему запросов к ДНС'у на разрешение подобного рода адресов очень мало. В смысле не думаю что из-за этого проблема. И кстати, какой адрес? - 188.40.77.142, если да, то тогда все норм.

Теперь понятно.

58.20.210.187, 118.213.153.154, 113.122.204.0, 46.71.33.184 и разные другие.

Да нет, не просто. Было бы все нормально, если бы к вашему ДНС отправлялись запросы извне на разрешение имен в доменной зоне, за которую он отвечает. А так, это вопрос к специалистам по компьютерной безопасности, с какой целью разрешать такие странные имена и получать по ним ошибку разрешения.

Смотрите прикрепленный файл. А вот с тем, что запрос уходит с внешней карточки не все так однозначно. Я возможно и ошибся в этом из-за того что смотрел бегло, поэтому данной информации по пакетам во вложенном файле нет. Когда найду достаточно времени для анализа, разберусь окончательно.

Сегодня 14.07.15 проблема повторилась.
Но в 1 момент не было доступа к почте и с сервера. Позже я выяснил что с сервера 14.07.15 так же не было доступа к почте, FTP.
Просто я всегда раньше проверял 1 раз. А сегодня – попробовал подключиться несколько раз подряд – и с сервера так же не смог подключиться к ресурсам.
Помогло отключение модема, не перезагрузка, а именно отключение на 5 мин, затем включение – и все восстановилось….
Получается, возможно проблема в модеме, или на стороне провайдера?
- Попробовать дождаться проблему еще раз, и еще раз проверить решится ли она выключением модема, и будет ли проблема так же на интернет-сервере, при неоднократном подключении к ресурсам?

Логи сетевого монитора выложу позже.

IT Shepherd, - Что думаете насчет этого?
Модем провайдерский - Alcatel Lucent I-240W-A - 1-я буква может быть L, не совсем понятно.
До настроек модема пока не добрался, но провайдер говорил что я ничего настраивать не смогу, т.к. управлять модемом удаленно могут только они. Никогда подобного не слышал...

IT_Shepherd, попутно вопрос - возможно ли в ДНС-сервере, который идет в с 2008R2 STD Виндой, настроить так чтобы извне он разрешал запросы, связанные только со своей зоной? - В настройках бегло глянул, не нашел.

Логи с клиента и сервера, собранные сетевым монитором:

Вчера 16.07.15 проблема повторилась опять. Но на этот раз доступ к ресурсам с интернет-сервера был...
Пробую озадачить провайдера по этой проблеме...
Может у кого появились какие-нибудь мысли?

Как насчет выключения модема? Опять помогло или нет?

Есть такая практика у провайдеров

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

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

От предыдущих постов прошло почти 2 месяца... Думаю, проблема решилась заменой модема.
Зачем пишу? Для других...
И у меня тоже были аналогичные проблемы в офисной сети, построенной на многочисленных свичах, - вдруг терялись отдельные ПК, никакие (пере)настройки не помогали... Оказалось, барахлил один свич. Далеко не центральный. Мучался долго... пока этот грёбаный свич не заменил. И стоит отметить, что терялся коннект между ПК, которые через этот свич данных не передавали! Собственно, по этой причине решал проблему долго... И ещё. "грёбаный " свич не умер - все порты работали... Через пол-года я его поставил в другую сеть из 2 ПК+инет-модем. И никаких проблем уже года два!

Еще периодически у меня возникает проблема "пропал общий инет". Стоит цепочка: инет-сервер с Керио - роутер - ДСЛ-модем. Методом тыка выяснил, что иногда виноват Сервер с Керио, иногда роутер, иногда ДСЛ-модем. "необходимо и достаточно" просто перезагрузить это "виноватое" устройство. Но чтобы не гадать - теперь перезагружаю (или OFF-ON) всё сразу. Если инет не восстановился - то звоню Провайдеру... Это редкий случай, в 90% глючит моё железо.

Итак. Последняя проблема была 17.07.15. Прошло 2 месяца, я уже облегченно вздохнул, и... Сегодня, 19.09.15, 15:15 (Астана) проблема повторилась. Во вложении лог сетевого монитора в момент проблемы, клиент - 192.168.1.48 пытался подключиться к почтовому серверу, безуспешно. Блин, непонятно в какую сторону копать сейчас. У кого какие мысли?
Интересно то, что проблема произошла в выходной день, в офисе включено всего несколько клиентских компов - не более 5 или 6, на которых сотрудники работают удаленно - т.е. вариант что проблема происходит из-за нагрузки, исключается. Так же интересно то, что проблема "ушла" в 16:55 по Астане, при этом я ничего не делал ( не успел).