У меня странная проблема.
Я работаю над правильной настройкой «Сайтов и подсетей», чтобы мои клиенты AD подключались к правильному DC (а не к одному на противоположной стороне земного шара).
Для этого я начал фильтровать журналы на DC на предмет ошибки «NO_CLIENT_SITE» - и, хотя большинство клиентских адресов я могу легко найти, некоторые из них ... невозможно.
Я использую исключительно частный IP-адрес в своей организации, некоторым людям разрешено использовать VPN (также используя частные IP-адреса для туннельного интерфейса). Но в журналах есть некоторые клиенты, которые сообщают об общедоступном IP-адресе или адресе APIPA, например:
24 мая, 16:28:45, APAC: NO_CLIENT_SITE: CN070E141 169.254.87.93
Откровенно говоря, это невозможно - я на 100% уверен, что клиент, использующий APIPA, не сможет никуда подключиться. Точно так же клиент, использующий общедоступный IP-адрес, не сможет связаться с DC.
Единственное объяснение, которое приходит мне в голову, заключается в том, что на клиенте есть несколько интерфейсов, один из которых работает нормально и обеспечивает связь с DC, а другой имеет APIPA или общедоступный IP-адрес, и этот адрес сообщается DC.
Это подводит меня к основному вопросу: как я могу убедиться, что адрес, предоставленный DC, всегда является адресом интерфейса, используемого для связи?
Или, может быть, кто-то может дать альтернативное объяснение?
Как только у клиента будет один хороший адрес, он сможет подключиться, и в этот момент, я думаю, он сообщает ВСЕ свои адреса. Я не знаю, как изменить это поведение.
Вы можете предотвратить NO_CLIENT_SITE ... 169 сообщения из журнала, если вы добавляете подсеть для 169.254.0.0/16 в конфигурацию вашего сайта. Неважно, на что он указывает.
Или просмотрите журнал немного иначе. Что-то вроде:
get-content netlogon.log | select-string -notmatch "NO_CLIENT_SITE: \S+ 169\.254"
Backslash Capital S Plus - регулярное выражение, которое будет соответствовать одному или нескольким непробельным символам, в данном случае имени клиента.