По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Первая часть статьи доступна по ссылке: Базовая настройка коммутатора Cisco - часть 1
Защита доступа в пользовательском режиме с помощью локальных имен пользователей и паролей
Коммутаторы Cisco поддерживают два других метода безопасного входа, которые используют пары имя пользователя / пароль вместо общего пароля без ввода имени пользователя. Первый метод, использует ввод локального имени пользователя и пароля. Происходит настройка пары имя пользователя / пароль локально-то есть в конфигурации коммутатора. Коммутаторы поддерживают режим локального имени пользователя / пароля для входа по консоли, по Telnet и даже по SSH, но не изменяют пароль от привилегированного режима (enable), используемый для входа в режим enable.
Настройки для перехода от использования простых общих паролей к использованию локальных имен пользователей/паролей требует лишь небольших изменений конфигурации, как показано на рис.3.
На рисунке показаны два ПК, пытающиеся получить доступ к пользовательскому режиму. Один из ПК подключен по консольному кабелю в пользовательский режим через линию console 0, а другой ПК по Telnet, соединяющийся через терминальные линии vty 0 15. Оба ПК не имеют паролей для входа, и задано имя пользователя для обоих ПК - " local."
На рисунке в Пользовательском режиме используется две команды:
1- username ulanbaby secret box
2- username landy secret box
Глядя на настройки на рисунке, видно, во-первых, коммутатору, необходимо задать пару имя пользователя/пароль. Для их создания, в режиме глобальной конфигурации, введите команду создания имени пользователя и зашифрованного пароля -username <имя пользователя> secret <пароль>. Затем, чтобы включить тип безопасности входа с проверкой логина (имени пользователя ) по консоли или Telnet, просто добавьте команду login local. По сути, эта команда означает " использовать локальный список имен пользователей для входа в систему."
Вы также можете использовать команду no password, чтобы очистить все оставшиеся команды паролей из консоли или режима vty, потому что эти команды не нужны при использовании локальных имен пользователей и паролей.
Ниже подробно описаны шаги для настройки доступа к к коммутатору с использованием логина и пароля:
Шаг 1. В режиме глобальной конфигурации используйте команду username <имя пользователя > secret <пароль>, чтобы создать одну или несколько пар имя пользователя/пароль в локальной базе коммутатора.
Шаг 2. Настройте консоль на использование пар имя пользователя / пароль из локальной базы коммутатора:
используйте команду line con 0 для входа в режим конфигурации консоли.
используйте подкоманду login local, чтобы разрешить коммутатору запрашивать имя пользователя и пароль, совпадающие со списком локальных имен пользователей/паролей.
(необязательно) используйте подкоманду no password для удаления всех существующих простых общих паролей, просто для оптимизации конфигурации.
Шаг 3. Настройте Telnet (vty) для использования пар имя пользователя / пароль из локальной базы коммутатора:
1. используйте команду line vty 0 15 для входа в режим конфигурации vty для всех 16 терминальных линий vty (пронумерованных от 0 до 15).
2. используйте подкоманду login local, чтобы разрешить коммутатору запрашивать имя пользователя и пароль для всех входящих пользователей Telnet, со списком локальных имен пользователей/паролей.
3. (необязательно) используйте подкоманду no password для удаления всех существующих простых общих паролей, просто для оптимизации конфигурации.
При попытке подключиться по Telnet к коммутатору, настроенному как показано на рисунке, пользователю будет предложено сначала ввести имя пользователя, а затем пароль, как показано в Примере 4. Пара имя пользователя / пароль должна быть в локальной базе коммутатора.В противном случае вход в систему будет отклонен.
В примере 4 коммутаторы Cisco не отображает символы при вводе пароля по соображениям безопасности.
Защита доступа в пользовательском режиме с помощью внешних серверов аутентификации
В конце примера 4 показано одно из многочисленных улучшений безопасности, когда требуется, чтобы каждый пользователь входил под своим собственным именем пользователя. Также в конце примера показано, как пользователь входит в режим конфигурации (configure terminal), а затем сразу же покидает его (end). Обратите внимание, что при выходе пользователя из режима конфигурации коммутатор генерирует сообщение журнала (log). Если пользователь вошел в систему с именем пользователя, сообщение журнала (log) идентифицирует это имя пользователя; В примере сгенерировано сообщение журнала по имени "ulanbaby".
Однако использование имени пользователя / пароля, настроенного непосредственно на коммутаторе, не всегда удобно при администрировании. Например, каждому коммутатору и маршрутизатору требуется настройка для всех пользователей, которым может потребоваться войти на устройства. Затем, когда возникнет необходимость внесения изменений в настройки, например, изменение паролей для усиления безопасности, настройки всех устройств должны быть изменены.
Лучшим вариантом было бы использовать инструменты, подобные тем, которые используются для многих других функций входа в ИТ. Эти инструменты обеспечивают центральное место для безопасного хранения всех пар имя пользователя / пароль, с инструментами, чтобы заставить пользователей регулярно менять свои пароли, инструменты, чтобы отключать пользователей, когда они завершают сеанс работы, и так далее.
Коммутаторы Cisco позволяют именно этот вариант, используя внешний сервер, называемый сервером аутентификации, авторизации и учета (authentication, authorization, and accounting)(AAA). Эти серверы содержат имена пользователей / пароли. Сегодня многие существующие сети используют AAA-серверы для входа на коммутаторы и маршрутизаторы.
Да для настройки данного входа по паре имя пользователя / пароль необходимо произвести дополнительные настройки коммутатора.
При использовании AAA-сервера для аутентификации коммутатор (или маршрутизатор) просто отправляет сообщение на AAA-сервер, спрашивая, разрешены ли имя пользователя и пароль, и AAA-сервер отвечает.
На рисунке показано, что пользователь сначала вводит имя пользователя / пароль, коммутатор запрашивает AAA-сервер, а сервер отвечает коммутатору, заявляя, что имя пользователя/пароль действительны.
На рисунке процесс начинается с того, что ПК " А " отправляет регистрационную информацию через Telnet или SSH на коммутатор SW1. Коммутатор передает полученную информацию на сервер "AAA" через RADIUS или TACACS+. Сервер отправляет подтверждение коммутатору, который, в свою очередь, отправляет приглашение (разрешение) на ввод команды в пользовательскую систему.
Хотя на рисунке показана общая идея, обратите внимание, что информация поступает с помощью нескольких различных протоколов. Слева, соединение между Пользователем и коммутатором или маршрутизатором использует Telnet или SSH. Справа коммутатор и AAA-сервер обычно используют протокол RADIUS или TACACS+, оба из которых шифруют пароли, при передаче данных по сети.
Настройка защищенного удаленного доступа по SSHl
До сих пор мы рассматривали доступ к коммутатору по консоли и Telnet, в основном игнорируя SSH. У Telnet есть один серьезный недостаток: все данные в сеансе Telnet передаются в открытом виде, включая обмен паролями. Таким образом, любой, кто может перехватывать сообщения между Пользователем и коммутатором (man-in-the-middle attack), может видеть пароли. SSH шифрует все данные, передаваемые между SSH-клиентом и сервером, защищая данные и пароли.
SSH может использовать тот же метод аутентификации локального входа, что и Telnet, с настроенными именем пользователя и паролем в локальной базе коммутатора. (SSH не работает с методами аутентификации, которые не используют имя пользователя, например только общие пароли.)
Итак, в настройке доступа для локальных пользователей по Telnet, как показано ранее на рисунке, также включена локальная аутентификация по имени пользователя для входящих соединений SSH.
На рисунке показан один пример настройки того, что требуется для поддержки SSH. Рисунок повторяет конфигурацию создания локального пользователя, (см. рисунок) для подключения по Telnet. На скриншоте показаны три дополнительные команды, необходимые для завершения настройки SSH на коммутаторе.
На рисунке показаны три дополнительные команды, необходимые для завершения настройки SSH на коммутаторе. На рисунке показан листинг настройки SSH. Для настройки SSH на рисунке, отображаются команды:
hostname sw-1 (задает имя коммутатору)
ip domain-name testing.com (команда использует полное доменное имя sw-1.testing.com)
crypto key generate rsa.
Для локальной конфигурации имени пользователя (например, Telnet) отображаются следующие команд:
username ulanbaby secret box
username landy secret man
line vty 0 15
login local
IOS использует три команды: две для конфигурации SSH, а также одну команду для создания ключей шифрования SSH. Сервер SSH использует полное доменное имя коммутатора в качестве входных данных для создания этого ключа. Коммутатор создает полное доменное имя из имени хоста и доменного имени коммутатора. Рисунок 5 начинается с установки обоих значений (на тот случай, если они еще не настроены). Затем третья команда, команда crypto key generate rsa, генерирует ключи шифрования SSH. IOS по умолчанию использует SSH-сервер. Кроме того, IOS по умолчанию разрешает SSH-соединения по vty.
Просмотр настроек в режиме конфигурации, шаг за шагом, может быть особенно полезен при настройке SSH. Обратите внимание, в частности, что в этом примере команда crypto key запрашивает у пользователя модуль ключа; вы также можете добавить параметр modulus modulus-value в конец команды crypto key, чтобы добавить этот параметр в команду. В примере 5 показан порядок настройки ssh ( такие же команды, что и на рис. 5) Ключ шифрования является последним шагом.
Ранее упоминалось, что одним полезным значением по умолчанию было то, что коммутатор по умолчанию поддерживает как SSH, так и Telnet на линиях vty. Однако, поскольку Telnet не безопасный протокол передачи данных, то вы можете отключить Telnet, чтобы обеспечить более жесткую политику безопасности.
Для управления тем, какие протоколы коммутатор поддерживает на своих линиях vty, используйте подкоманду transport input {all | none / telnet / ssh} vty в режиме vty со следующими опциями:
transport input all or transport input telnet ssh поддержка как Telnet, так и SSH
transport input none: не поддерживается ни один протокол
transport input telnet: поддержка только Telnet
transport input ssh: поддержка только SSH
В завершении этой части статьи о SSH, расписана пошаговая инструкция настройки коммутатора Cisco для поддержки SSH с использованием локальных имен пользователей. (Поддержка SSH в IOS может быть настроена несколькими способами; эта пошаговая инструкция показывает один простой способ ее настройки.)
Процесс, показанный здесь, заканчивается инструкцией настройки локального имени пользователя на линиях vty, как было обсуждено ранее в первой части данной серии статей.
Шаг 1. Настройте коммутатор так, чтобы он генерировал совпадающую пару открытых и закрытых ключей для шифрования:
если еще не настроено, задайте командой hostnamename имя для этого коммутатора в режиме глобальной конфигурации.
Если еще не настроено, задайте командой ip domain-namename доменное имя для коммутатора в режиме глобальной конфигурации.
Используйте команду crypto key generate rsa в режиме глобальной конфигурации (или команду crypto key generate RSA modulus modulus-value, чтобы избежать запроса модуля ключа) для генерации ключей. (Используйте по крайней мере 768-битный ключ для поддержки SSH версии 2.)
Шаг 2. (Необязательно) используйте команду ip ssh version 2 в режиме глобальной конфигурации, чтобы переопределить значение по умолчанию для поддержки обеих версий протокола удаленного доступа SSH 1 и 2, так что бы разрешены были только соединения SSHv2.
Шаг 3. (Необязательно) если вы еще не настроили нужный параметр, задайте на линии vty для работы по SSH и Telnet.:
используйте команду transport input ssh в режиме конфигурации линий vty, чтобы разрешить только SSH.
используйте команду transport input all (по умолчанию) или команду transport input telnet ssh в режиме конфигурации линий vty, чтобы разрешить как SSH, так и Telnet.
Шаг 4. Используйте различные команды в режиме конфигурации линий vty для настройки локальной аутентификации имени пользователя, как описано ранее в этой статье.
На маршрутизаторах Cisco часто по умолчанию настроен параметр transport input none. Поэтому необходимо добавить подкоманду transport input line для включения Telnet и / или SSH в маршрутизаторе.
Для просмотра информации о состояния SSH на коммутаторе используются две команды. Во-первых, команда show ip ssh выводит информацию о состоянии самого SSH-сервера. Затем команда show ssh выводит информацию о каждом клиенте SSH, подключенном в данный момент к коммутатору. В пример 6 показаны примеры работы каждой из команд, причем пользователь ULANBABY в данный момент подключен к коммутатору.
Теперь мы можем продолжить поиск и устранение неисправностей. В большинстве случаев вы ожидаете увидеть определенную сеть в таблице маршрутизации, но ее там нет. Далее рассмотрим несколько сценариев неправильной (или полностью не рабочей) работы EIGRP и как исправить наиболее распространенные ошибки. Ниже перечислены часто встречающиеся ошибки:
Первую часть статьи про траблшутинг EIGRP можно почитать здесь.
Кто-то настроил distribute-list, чтобы информация о маршрутах фильтровалась.
Было настроено автосуммирование или кто-то настроил суммирование вручную
Split-horizon блокирует объявление маршрутной информации.
Перераспределение было настроено, но информация из EIGRP не используется.
Перераспределение было настроено, но никакие внешние маршруты EIGRP не отображаются.
Case #1
Давайте начнем с простой топологии. OFF1 и OFF2 работают под управлением EIGRP, и каждый маршрутизатор имеет интерфейс обратной связи. Вот конфигурация обоих маршрутизаторов:
OFF1(config)#router eigrp 12
OFF1(config-router)#no auto-summary
OFF1(config-router)#network 1.1.1.0 0.0.0.255
OFF1(config-router)#network 192.168.12.0 0.0.0.255
OFF2(config)#router eigrp 12
OFF2(config-router)#no auto-summary
OFF2(config-router)#network 2.2.2.0 0.0.0.255
OFF2(config-router)#network 192.168.12.0 0.0.0.255
Все работает нормально, пока через пару недель один из пользователей не пожаловался на то, что ему не удалось подключиться к сети 2.2.2.0 / 24 из-за OFF1. Посмотрите на таблицу маршрутизации на OFF1, и вот что вы видите:
По какой-то причине нет сети 2.2.2.0 / 24 в таблице маршрутизации.
Видно, что на OFF1 не настроен distribute lists.
OFF2 содержит сеть 1.1.1.0 / 24 в своей таблице маршрутизации. Давайте выполним быструю отладку, чтобы увидеть, что происходит.
Отладка показывает нам, что происходит. Прежде чем вы увидите это сообщение, придется немного подождать, или вы можете сбросить соседство EIGRP, чтобы ускорить процесс. Как видите, в сети 2.2.2.0 / 24 отказано из-за distribute list.
Другой быстрый способ проверить это - использовать команду show ip protocol.
В этом случае использование show run могло бы быстрее обнаружить distribute-list.
Вот список доступа, доставляющий нам неприятности.
OFF2(config)#router eigrp 12
OFF2(config-router)#no distribute-list 1 out
Удалим distribute-list.
Задача решена!
Извлеченный урок: если команды network верны, проверьте, есть ли у вас distribute-list, который запрещает объявлять префиксы или устанавливать их в таблицу маршрутизации.
Имейте в виду, distribute-list могут быть настроены как входящие или исходящие, как список доступа.
Case #2
В следующем сценарии те же 2 маршрутизатора, но разные сети в loopback. Вот конфигурация:
OFF1(config)#router eigrp 12
OFF1(config-router)#network 192.168.12.0
OFF1(config-router)#network 10.0.0.0
OFF2(config)#router eigrp 12
OFF2(config-router)#network 192.168.12.0
OFF2(config-router)#network 10.0.0.0
Как вы видите - это довольно базовая конфигурация.
Глядя на таблицы маршрутизации, не видно сети 10.1.1.0 / 24 или 10.2.2.0 / 24. Видна запись для сети 10.0.0.0/8, указывающую на интерфейс null0. Эта запись отображается только при настройке суммирования и используется для предотвращения циклов маршрутизации.
Давайте включим отладку и посмотрим, что мы можем найти.
OFF2#clear ip eigrp 12 neighbors
Этой командой мы сделаем сброс соседства EIGRP, чтобы ускорить процесс. Имейте в виду, что это, вероятно, не самое лучшее, что можно сделать в производственной сети, пока вы не узнаете, что не так, но это действительно помогает ускорить процесс.
Вот наш ответ. Отладка говорит нам, что сеть 10.2.2.0 / 24 не следует объявлять, а сеть 10.0.0.0 / 8 нужно объявлять (это вкратце). Это может произойти по двум причинам:
Суммирование было кем-то настроено
Авто-суммирование включено для EIGRP.
Как вы видите, авто-суммирование включено для EIGRP. В зависимости от версии IOS авто-суммирование включено или отключено по умолчанию.
OFF1(config)#router eigrp 12
OFF1(config-router)#no auto-summary
OFF2(config)#router eigrp 12
OFF2(config-router)#no auto-summary
Отключение автоматического суммирования должно помочь.
Ну что, наши сети появились в таблице маршрутизации.
Извлеченный урок: если включена автоматическое суммирование EIGRP, вы можете столкнуться с нестабильными сетями.
Case #3
Очередная проблема. В приведенном выше примере у нас есть 2 маршрутизатора, но разные сети. OFF1 содержит сеть 172.16.1.0 / 24 на интерфейсе обратной связи, а OFF2 содержит сеть 172.16.2.0 / 24 и 172.16.22.0 / 24 на своих интерфейсах обратной связи. Посмотрим конфигурацию EIGRP обоих маршрутизаторов:
Как вы видите, что все сети объявляются. Обратите внимание, что в OFF1 включено автоматическое суммирование, а в OFF2 отключено автоматическое суммирование.
Кто-то настроил суммирование на OFF2 и отправляет ее на OFF1. Суммирование создана для сети 172.16.0.0 / 16.
Однако, если посмотреть на таблицу маршрутизации OFF1, она не появится. Мы видим запись для сети 172.16.0.0 / 16, но она указывает на интерфейс null0, а не на OFF2. Что здесь происходит?
OFF2#clear ip eigrp 12 neighbors
Давайте сделаем отладку на OFF2, чтобы увидеть, объявляется ли суммирование. Выполним команду clear ip eigrp neighbors, просто чтобы ускорить процесс.
Глядя на отладку, видно, что OFF2 работает правильно. Он объявляет сводный маршрут 172.16.0.0 / 16 так, как должен. Это означает, что проблема должна быть в OFF1.
Давайте проведем отладку OFF1.
Мы можем видеть, что OFF1 получает сводный маршрут от OFF2, но решает не использовать его.
Это хороший момент для проверки таблицы топологии EIGRP. Вы видите, что он имеет суммирование сети 172.16.0.0 / 16 от OFF2 в своей таблице топологии EIGRP, но OFF1 решает не использовать ее, потому что вход через интерфейс null0 является лучшим путем.
OFF1(config)#router eigrp 12
OFF1(config-router)#no auto-summary
Решение состоит в том, что нам нужно избавиться от записи null0 в таблице маршрутизации. Единственный способ сделать это - отключить автоматическое суммирование.
Отключение автоматического суммирования удаляет запись null0, и теперь суммирование OFF2 установлено проблема решена!
Извлеченный урок: автоматическое суммирование EIGRP создает запись через интерфейс null0, которая может помешать установке суммирования, которые вы получаете от соседних маршрутизаторов.
Case #4
Есть еще одна проблема с суммированием, которую сейчас и разберем. Мы используем топологию, которую вы видите выше, и ниже конфигурация EIGRP обоих маршрутизаторов.
Все сети объявлены, и автоматическое суммирование отключено на обоих маршрутизаторах.
Суммирование было настроено на OFF2 и должно быть объявлено к OFF1.
К сожалению, ничего не видно на OFF1. Давайте проверим OFF2, чтобы посмотреть, что не так.
Когда дело доходит до устранения неполадок с сетью, вашими друзьями являются не Google или Яндекс, а команды Debug и show.
Странно, это единственная сеть, которую OFF2 объявляет.
Одно из золотых правил маршрутизации: вы не можете объявлять то, чего у вас нет. Очевидно, OFF2 знает только о сети 192.168.12.0 / 24.
Вот это ошибка! Кто-то выполнил команду отключения на интерфейсах обратной связи.
OFF2(config)#interface loopback 0
OFF2(config-if)#no shutdown
OFF2(config)#interface loopback 1
OFF2(config-if)#no shutdown
Включим интерфейсы.
Теперь мы видим, что суммирование объявляется.
Теперь мы видим суммирование в таблице маршрутизации OFF1- проблема решена!
Извлеченный урок: вы не можете объявлять то, чего у вас нет в таблице маршрутизации.
ВАЖНО. Последняя проблема может быть показаться простой, но есть важный момент, который вы не должны забывать: для объявления итогового маршрута в таблице маршрутизации объявляемого маршрутизатора должен быть указан хотя бы один префикс, попадающий в итоговый диапазон!
Case #5
Давайте посмотрим на другую топологию. На рисунке выше у нас есть концентратор Frame Relay и соответствующая топология. Каждый из OFF1 и OFF2 имеет интерфейс обратной связи, который мы будем объявлять в EIGRP. Вот соответствующая конфигурация всех маршрутизаторов:
CONC(config)#router eigrp 123
CONC(config-router)#no auto-summary
CONC(config-router)#network 192.168.123.0
OFF1(config-if)#router eigrp 123
OFF1(config-router)#no auto-summary
OFF1(config-router)#network 192.168.123.0
OFF1(config-router)#network 2.2.2.0 0.0.0.255
OFF2(config)#router eigrp 123
OFF2(config-router)#no auto-summary
OFF2(config-router)#network 192.168.123.0
OFF2(config-router)#network 3.3.3.0 0.0.0.255
Видно, что все сети объявлены.
Наш концентратор-маршрутизатор видит сети из двух OFF-маршрутизаторов.
К сожалению, наши маршрутизаторы не видят ничего ...
Похоже, что маршрутизатор-концентратор не объявляет сети, которые он изучает с помощью OFF-маршрутизаторов. Давайте включим отладку, чтобы увидеть, что происходит.
CONC#clear ip eigrp 123 neighbors
Сбросим соседство EIGRP, чтобы ускорить процесс.
В отладке мы видим, что наш маршрутизатор-концентратор узнает о сети 2.2.2.0 / 24 и 3.3.3.0 / 24, но объявляет только сеть 192.168.123.0 / 24 для OFF-маршрутизаторов. Разделение горизонта не позволяет размещать объявление от одного маршрутизатора на другой.
CONC(config)#interface serial 0/0
CONC(config-if)#no ip split-horizon eigrp 123
Давайте отключим разделение горизонта на последовательном интерфейсе маршрутизатора-концентратора.
Теперь мы видим, что маршрутизатор-концентратор объявляет все сети.
OFF-маршрутизаторы теперь могут узнавать о сетях друг друга, поскольку split horizon отключено. Это хорошо, но это еще не все.
Извлеченный урок: RIP и EIGRP являются протоколами маршрутизации на расстоянии и используют split horizon. Split horizon предотвращает объявление префикса вне интерфейса, на котором мы его узнали.
Хотя сети отображаются в таблицах маршрутизации мы не можем пропинговать от одного OFF-маршрутизатора к другому. Это не проблема EIGRP, но она связана с Frame Relay. Мы должны это исправить.
Когда OFF1 отправляет IP-пакет на OFF2, IP-пакет выглядит следующим образом:
Давайте пока подумаем, как роутер, и посмотрим, что здесь происходит. Сначала нам нужно проверить, знает ли OFF1, куда отправить 3.3.3.3:
Существует запись для 3.3.3.3, а IP-адрес следующего перехода - 192.168.123.1 (маршрутизатор-концентратор). Можем ли мы достичь 192.168.123.1?
Нет проблем, кажется, OFF1 может пересылать пакеты, предназначенные для сети 3.3.3.0/24. Давайте перейдем к маршрутизатору CONC.
У маршрутизатора-концентратора нет проблем с отправкой трафика в сеть 3.3.3.0 / 24, поэтому на данный момент мы можем сделать вывод, что проблема должна быть в маршрутизаторе OFF2.
Это IP-пакет, который получает маршрутизатор OFF2, и когда он отвечает, он создает новый IP-пакет, который выглядит следующим образом:
Способен ли OFF2 достигать IP-адрес 192.168.123.2 Давайте узнаем!
Теперь мы знаем проблему ... OFF2 не может достичь IP-адреса 192.168.123.2
Если мы посмотрим на таблицу маршрутизации OFF2, то увидим, что сеть 192.168.123.0 / 24 подключена напрямую. С точки зрения третьего уровня у нас нет никаких проблем. Пришло время перейти вниз по модели OSI и проверить уровень 2 ... или, может быть, между уровнем 2 и 3.
Frame Relay использует Inverse ARP для привязки уровня 2 (DLCI) к уровню 3 (IP-адрес). Вы можете видеть, что нет сопоставления для IP-адреса 192.168.123.2.
OFF2(config)#int s0/0
OFF2(config-if)#frame-relay map ip 192.168.123.2 301
Давайте frame-relay map сами.
Теперь роутер OFF2 знает, как связаться с роутером OFF1
Наконец, маршрутизатор OFF1 может пропинговать интерфейс обратной связи маршрутизатора OFF2. Когда мы пытаемся пропинговать от маршрутизатора OFF2 к интерфейсу обратной связи маршрутизатора OFF1, у нас возникает та же проблема, поэтому мы также добавим туда оператор frame-relay map:
OFF1(config)#int s0/0
OFF1(config-if)#frame-relay map ip 192.168.123.3 201
Теперь у нас есть extra frame-relay map на маршрутизаторе OFF1.
И наш пинг проходит!
Сегодня в статье я хочу затронуть вопрос удаленного включения RDP, он же удаленный рабочий стол. Все хоть раз пользовались этой незаменимой фичей, а кто-то использует ее для администрирования на ежедневной основе.
По умолчанию, на серверных платформах Windows удаленное управление (WinRM) включено, но функция удаленного рабочего стола выключена, а на десктопной версии обе функции выключены по умолчанию, поэтому, для выполнения описанного ниже, в начале придется включить WinRM на десктопе.
Итак, перейдем к методам - далее описаны непосредственно способы включения и отключения RDP (входит и замечательно выходит!)
Метод номер один: командная строка
Для включения удаленного рабочего стола (RDP) через командную строку, выполните следующее:
Запустите командную строку от имени администратора;
Выполните следующую команду:
Reg add “\computernameHKLMSYSTEMCurentControlSetControlTerminal Server” /v fDenyTSConnections /t REG_DWORD /d /f
В свою очередь, чтобы выключить RDP через командную строку, следуйте следующим шагам:
Запустите командную строку;
Выполните команду:
Reg add “\computernameHKLM SYSTEMCurentControlSetControlTerminal Server” /v fDenyTSConnections /t REG_DWORD /d 1 /f
Метод номер два: используем PowerShell
Для того, чтобы включить RDP через PowerShell, выполните следующие действия:
Способ 1: Для включения удаленного рабочего стола:
Запустите PowerShell от имени администратора;
Запустите следующую команду и используйте метод Invoke-Command:
Invoke-Command –Computername “server1”, “Server2” –ScriptBlock {Set-ItemProperty -Path "HKLM:SystemCurrentControlSetControlTerminal Server" -Name "fDenyTSConnections" –Value }
Далее введите команду:
Invoke-Command –Computername “server1”, “Server2” –ScriptBlock {Enable-NetFirewallRule -DisplayGroup "Remote Desktop"}
И, как традиция, обратные шаги:
Запускаем PowerShell от имени админа;
Вводим команду:
Invoke-Command –Computername “server1”, “Server2” –ScriptBlock {Set-ItemProperty -Path "HKLM:SystemCurrentControlSetControlTerminal Server" -Name "fDenyTSConnections" –Value 1}
Второй способ включения через PowerShell:
Запускаем PowerShell от имени админа и создаем PowerShell сессию с нужным компьютером;
Введите команду:
Set-ItemProperty -Path "HKLM:SystemCurrentControlSetControlTerminal Server" -Name "fDenyTSConnections" –Value
И следующую команду:
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
Чтобы выключить:
Повторяем первые два шага из предыдущего пункта (про повершелл и сессию);
Вводим команду:
Set-ItemProperty -Path "HKLM:SystemCurrentControlSetControlTerminal Server" -Name "fDenyTSConnections" –Value 1
Важно: Computername - это имя компьютера, на котором будет включен RDP.
Важно: Включение удаленного рабочего стола через командную строку не настроит фаервол с точки зрения использования правильных портов для того, чтобы разрешить RDP подключения.
Важно: По умолчанию, только локальные Администраторы и пользователь, который уже вошел в систему, смогут использовать RDP.
И в заключение
На этом все, надеюсь, было полезно! И помните, если вы даете кому-нибудь доступ по RDP на компьютер в вашей сети, это несет в себе риски - вы должны быть уверены в человеке, который будет заходить по RDP и в том, что доступ дан через защищенный канал связи!