История не о победе, а о траблшутинге
Недавно на работе обнаружился легкий трешачок. Как это было: внезапно посыпались заявки «не работает интернет». Быстро выяснилось, что с этих компьютеров прокся (Forefront TMG) не аллё – не пингуется. Методом научного тыка (самый быстрый метод) выясняли, что если пингануть проблемный комп с прокси – проблема уходит. Тестировать было некогда - вой не прекращался, так как 180 компов не напингуешься (конечно, скрипты, да. Интересно, стресс-собеседования проходят примерно так?), а пинг на широковещательный адрес нужного эффекта не давал. День мы продержались. Вечером ничего не нашли, к утру проблема не ушла, всех перекинули на резервный канал без всякой прокси и стали вдумчиво разбираться. Кого интересует чисто результат – пролистывайте вниз.
Что первое приходит в голову? Да сама прокся чудит. Добавлены несколько правил, впрямую разрешающие любой трафик из локальной сети к localhost и обратно, из локалки в локалку и т.д. Поднят им приоритет по самое некуда. Медитирую на простыню логов Forefront и тут вопрос: а где, собственно, request’ы? Не приходят. То есть, не режутся, а их вообще нет.
Прокся временно реабилитирована, но не забыта. Ставлю Wireshark на клиенте и на сервере и снова медитирую на простыню с пакетиками. Оппа, на клиенте arp-запрос who-has есть, а на сервере нет. То есть клиент спрашивает «у кого адрес 10.77.10.1?» широковещательно, а этот запрос приходит всем, кроме самой прокси! Ясен перец, ничего не пингуется – записи в arp-таблице у клиента нет.
Переставлены дрова на сетевую карту. Не помогло. Обновлён BIOS – аналогично. Смена IP – всё то же самое.
Под подозрение попал свич и я позвонила нашему цискарю. Свич был быстро реабилитирован, зато прибавилось идей.
Итак, для чистоты эксперимента был взят свич из коробки с дефолтными заводскими настройками и никогда не подключавшийся к нашей сети. В него воткнута прокся, ноутбук вне домена и еще раз ноутбук (через хвост USB-LAN). Зазеркалированы порты ноутбука и прокси в третий порт (как по очереди, так и оба сразу) и с третьего порта снят лог Wireshark’ом.
Результат: на порт сервера на свиче arp-запрос приходит, а вот на сам сервер уже нет. Как только с сервера уходит симметричный запрос who-has с адресом клиента, на сервер тут же проваливается клиентский запрос, с сервера уходит ответ с MAC-адресом и всё становится хорошо до протухания записи в arp-таблице клиента.
Что ещё проверено. С Debian live-cd ситуация ровно аналогичная. С другой виндой (уже без следов прокси) – тоже. С сетевого оборудования в качестве клиента тоже. При прописывании руками статической записи в arp-таблицу клиента всё работает. Кстати, вы знали, что «arp –s» в новой винде уже не работает? Вместо него используется команда powershell New-NetNeighbor.
Было также обращение в техподдержку производителей сервера. Сервак уже не на гарантии, но всё же. Посоветовали перевести IPMI из Failover в Dedicated. Не помогло.
Никто из моего окружения сказать в чем может быть проблема не смог, поэтому был сделан вывод «в физике» и с чистой совестью куплена еще одна сетевуха. На просторах инета находила еще две аналогичные ситуации, проблема там также не была решена.
Как можно обойти, если нет возможности заменить сетевуху: прописыванием на каком-нибудь сетевом оборудовании статической записи arp и перенаправлением всех клиентов через это оборудование. Или (если это прокся) в проблемный порт втыкается провод от провайдера и прописывается статическая запись у провайдера.
Всё происходило на материнке supermicro с одним из портов встроенной сетевухи. В тех двух случаях из инета тоже были материнки supermicro, так что какая-никакая, а статистика.
P.S.: для чего и кого этот пост? Для тех админов, которые, возможно, тоже с этим столкнутся. Чтоб была хоть какая информация на русском языке. Чтобы им было легче локализовать проблему. А может, кто и подскажет чего, чем черт не шутит - пикабу богат на таланты.
