☰

Как получить доступ к машине с неправильным сетевым адресом?

tag-icon • tag-icon windows active-directory local-area-network connection
Как получить доступ к машине с неправильным сетевым адресом?

У меня есть сеть Windows Active Directory в локальной сети с адресами 192.168.10.0/24. У меня есть другой сайт с адресами 192.168.11.0/24, где все серверы AD находятся на сайте 192.168.10.0/24 (я знаю, плохо!). Оба шлюза используют брандмауэры Fortigate и связаны через туннель Fortinet IPsec, поэтому машины с обеих сторон могут получать доступ друг к другу.

Случайно машина была настроена со статическим IP 192.168.10.36 и отправлена ​​на другую сторону, где нет сотрудников ИТ-отдела. Теперь мы не можем получить доступ к машине из-за неправильной адресации, и следующие решения не работают:

  • Войдите в систему как локальный администратор, поскольку эта возможность отключена.
  • Войдите в систему как администратор AD, поскольку устройство не может получить доступ к серверу AD.
  • Измените таблицу маршрутизации, потому что если мы изменим адрес брандмауэра другой стороны на 192.168.10.X, то нас вырубит.

Какие еще варианты у нас есть? Я ищу:

  • Способ изменить IP-адрес. Есть кэшированный пользователь домена, который может войти, но он не является администратором. Или,
  • Способ восстановить соединение, чтобы мы могли войти в систему и изменить IP-адрес, или
  • Любое другое решение, восстанавливающее доступ к машине.

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

решение1

Я предполагаю, что у вашего проблемного ящика есть следующие настройки:

  • IP = 192.168.10.36, шлюз по умолчанию = 192.168.10.1, DNS = 192.168.10.2 (в противном случае измените указанные ниже числа).

Теперь действуйте следующим образом, используя два ящика TEMPAD (скажем, с IP-адресом 192.168.11.100) и TEMPDNS (скажем, с IP-адресом 192.168.11.200):

  1. RDP в TEMPAD и установка роли AD на TEMPAD
  2. На TEMPAD установите статический маршрут к хосту(!) 192.168.10.36 через 192.168.11.200
  3. Из сеанса RDP на TEMPAD запустите сеанс RDP на TEMPAD и установите DNS на TEMPDNS. Он должен обслуживать вашу зону AD; я не уверен, должен ли он обслуживатьискалеченныйЗона AD со всеми ссылками на серверы AD 192.168.10.* удалена, см. подсказки ниже.
  4. Добавьте вторичные IP-адреса 192.168.10.1/24 и 192.168.10.2/24 на TEMPDNS и включите переадресацию IP-адресов.
  5. Попросите человека на сайте 192.168.11.* включить проблемный компьютер.
  6. После завершения загрузки запустите сеанс RDP на 192.168.10.36 из сеанса RDP на TEMPAD. Теперь вы можете войти в систему как кто угодно.

Примечание:Четвертый шаг прерывает подключение от TEMPDNS к вашей локальной сети 192.168.10.*, но ваш удаленный сеанс все еще работает, поскольку он фактически исходит от TEMPAD в локальной сети 192.168.11.*

На шаге 6 происходит следующее волшебство (я надеюсь): машина запрашивает у своего настроенного DNS-сервера 192.168.10.2 (т. е. TEMPDNS) адрес сервера AD. В ответ она получает ваши исходные серверы AD в 192.168.10.* и 192.168.11.200 (т. е. TEMPAD). Попытки подключения к серверам AD 192.168.10.* терпят неудачу, поэтому в конечном итоге пробуется 192.168.11.200 (как я уже сказал, может быть лучше избегать попыток подключения к 192.168.10.*, парализовав DNS на TEMPDNS). Подключение к 192.168.11.200 успешно установлено: у нас есть рабочий прямой маршрут 192.168.10.36 -> 192.168.10.1=TEMPDNS -> TEMPAD и обратный маршрут TEMPAD -> 192.168.10.200=TEMPAD -> 192.168.10.36.

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

решение2

Хм... список отсортирован от наименьшего взаимодействия с пользователем до наибольшего взаимодействия с пользователем:

  1. Сегментируйте систему в их собственную VLAN, направьте эту VLAN обратно в известный хороший сегмент LAN (убедитесь, что нет перекрытий в IP-пространстве!). Войдите в систему, исправьте ошибки, сбросьте порт коммутатора на локальную VLAN, попробуйте снова получить доступ.
  2. Подготовьте загрузочный компакт-диск, который предоставляет доступ к удаленному рабочему столу, и ntpasswdотправьте его по почте в удаленный офис, чтобы пользователь загрузил его и использовал хороший IP-адрес для местоположения. (Здесь могут возникнуть проблемы, вам придется провести пользователя через все этапы настройки)
  3. Возьмите другой аналогичный жесткий диск и ноутбук, переименуйте, исправьте свои ошибки, отправьте Fedex, попросите пользователей поменять диски. (Пользователь должен иметь возможность менять диски и загружать компьютер).

решение3

Не могли бы вы отправить им многосетевой ящик, настроенный как маршрутизатор по умолчанию или контроллер домена для 192.168.10 и как обычная машина на 192.168.11? Может быть, тогда вы могли бы подключиться к стороне .11 и проксировать через .10. (Вовсе не эксперт по AD — просто думаю об общем случае.) .10 и новый ящик можно было бы соединить кроссовером, если необходимо.

решение4

Вы пробовали безопасный режим и следующую команду: "net user administrator /active:yes". Я однажды отключил учетную запись локального администратора и на компьютере были только неадминистративные локальные учетные записи. Я сделал эту команду и включил ее. Также вы всегда можете нанять компанию по предоставлению ИТ-услуг, чтобы она прислала местного техника, чтобы помочь вам, ребята.

Связанный контент