Если у вас происходит необъяснимая фигня в сети, не поддающаяся логике. Если соединения то проходят, то не проходят. Если соединения идут, но не все.
Есть ровно один главный кандидат - DNS. И два его подручных - BGP и DHCP.
Давайте поговорим о диагностике участия DNS. Я в очередной раз потратил три дня на раскопки и разборки с системным ПО из-за DNS, поэтому будет и мне напоминанием. Все приведенные кейсы реальны.
1. Кейс об отсутствующих DC/DNS
В системе VDI происходит длительный логин, иногда до 30 секунд ожидания. Все бы ничего, но в ней работает от силы 30 пользователей.
Причина - исторически сложилось, что в терминальном брокере были прописаны DNS3, DNS2 (совмещенная роль AD/DNS), но по ходу эксплуатации DNS3 остался резервным и перешли на DNS1, DNS2. И при очередных работах DNS3 просто забыли включить назад. Сменили на брокере DNS на актуальные - логин стал моментальным.
2. Кейс о нестабильном сетевом коннекте.
Сервер приложений то отвечает, то не отвечает. Любые корреляции случайны, включая фазы луны. Обращение в ТП сервера приложений стало просто анекдотичным.
- Пришлите нам tcpdump
- Вот, смотрите - запрос есть, ответа нет
- А вот смотрите у нас в лабе есть запрос и есть ответ.
- Алло, пожарные, у меня 9-этажка напротив горит!
- Да? А у меня напротив такая ж 9-этажка и не горит.
Технологический ландшафт. В конторе две технических службы, одна из которых классические офисные ИТ, а вторая тоже ИТ, но не офисная от слова совсем. Сервер приложений в ведении ИТ2, и у ИТ2 даже свой собственный сетевой сегмент, свои серверы и даже маленький технологический домен с собственными DNS.
На серверах DNS ИТ2 стоит безусловный форвард на DNS ИТ1 всех неизвестных запросов.
Причина. Сервер приложений по какой-то неизвестной причине обязательно делал реверс-DNS запрос по каждому клиенту. Поскольку обращение к серверу приложений в технологической зоне шло с офисной машины администратора, то реверс-запрос сразу форвардился на DNS ИТ1, а там на одном из трех DNS были в наличии не все реверс-зоны.
Потеряно 3 недели и целая куча нервов во взаимных обвинениях между ИТ1, ИТ2 и разработчиком сервера приложений.
3. Кейс о машинах VDI, которые то добавляются, то не добавляются
Администратор создает VDI машины и добавляет их в пул. Но иногда случается ситуация, что машина добавляется на пол-шишечки. Т.е. все всех видят, стабильная сетевая связность, но агент не может соединиться с брокером. При этом сетевая связность машины (на которой агент) с сервером (на котором брокер) есть и безупречная - 25 Gbit один хоп.
Причина. Машины VDI находятся в зоне технологической лаборатории и бывает так, что в DNS остались записи на тот же IP, а часть записей никто не вносил. Судя по всему, снюхивание агента с брокером зависит от DNS и в частности реверс-DNS, поэтому очистка DNS от лишнего и прописывание прямых и обратных адресов сработала.
Итоговая методичка по проверке DNS
1. Нарисуй структуру всех участвующих DNS и кто кому форвардит
2. Разбей DNS на группы, и напиши какие группы отвечают за какие зоны
3. Проверь, что репликация зон настроена на всех DNS из каждой группы
4. Проверь, что на всех DNS есть все зоны, включая обратные зоны
5. Проверь, что нет лишних записей с теми же адресами
6. Проверь, что все адреса внесены в DNS, включая обратные зоны