По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Всем привет! Сегодня в статье мы расскажем про настройку Point-to-Point GRE VPN туннелей на оборудовании Cisco и о том, как сделать их защищенными при помощи IPsec. Generic Routing Encapsulation (GRE) - это протокол туннелирования, разработанный компанией Cisco, который позволяет инкапсулировать широкий спектр протоколов сетевого уровня в point-to-point каналах.
Туннель GRE используется, когда пакеты должны быть отправлены из одной сети в другую через Интернет или незащищенную сеть. В GRE виртуальный туннель создается между двумя конечными точками (маршрутизаторами Cisco), а пакеты отправляются через туннель GRE.
Важно отметить, что пакеты, проходящие внутри туннеля GRE, не шифруются, поскольку GRE не шифрует туннель, а инкапсулирует его с заголовком GRE. Если требуется защита данных, IPSec должен быть настроен для обеспечения конфиденциальности данных - тогда GRE-туннель преобразуется в безопасный VPN-туннель GRE.
На приведенной ниже схеме показана процедура инкапсуляции простого незащищенного пакета GRE, проходящего через маршрутизатор и входящего в туннельный интерфейс:
Хотя многие могут подумать, что туннель GRE IPSec между двумя маршрутизаторами похож на VPN-соединение IPSec между сайтами, это не так. Основное отличие состоит в том, что туннели GRE позволяют multicast пакетам проходить через туннель, тогда как IPSec VPN не поддерживает multicast пакеты.
В больших сетях, где необходимы протоколы маршрутизации, такие как OSPF, EIGRP, туннели GRE - ваш лучший выбор. По этой причине, а также из-за того, что туннели GRE гораздо проще в настройке, инженеры предпочитают использовать GRE, а не IPSec VPN.
В этой статье объясняется, как создавать простые незащищенные (unprotected) и безопасные (IPSec encrypted) туннели GRE между конечными точками. Мы объясним все необходимые шаги для создания и проверки туннеля GRE (незащищенного и защищенного) и настройки маршрутизации между двумя сетями.
Создание Cisco GRE туннеля
Туннель GRE использует интерфейс «туннель» - логический интерфейс, настроенный на маршрутизаторе с IP-адресом, где пакеты инкапсулируются и декапсулируются при входе или выходе из туннеля GRE.
Первым шагом является создание нашего туннельного интерфейса на R1:
R1(config)# interface Tunnel0
R1(config-if)# ip address 172.16.0.1 255.255.255.0
R1(config-if)# ip mtu 1400
R1(config-if)# ip tcp adjust-mss 1360
R1(config-if)# tunnel source 1.1.1.10
R1(config-if)# tunnel destination 2.2.2.10
Все туннельные интерфейсы участвующих маршрутизаторов всегда должны быть настроены с IP-адресом, который не используется где-либо еще в сети. Каждому туннельному интерфейсу назначается IP-адрес в той же сети, что и другим туннельным интерфейсам.
В нашем примере оба туннельных интерфейса являются частью сети 172.16.0.0/24.
Поскольку GRE является протоколом инкапсуляции, мы устанавливаем максимальную единицу передачи (MTU - Maximum Transfer Unit) до 1400 байт, а максимальный размер сегмента (MSS - Maximum Segment Size) - до 1360 байт. Поскольку большинство транспортных MTU имеют размер 1500 байт и у нас есть дополнительные издержки из-за GRE, мы должны уменьшить MTU для учета дополнительных служебных данных. Установка 1400 является обычной практикой и гарантирует, что ненужная фрагментация пакетов будет сведена к минимуму.
В заключение мы определяем туннельный источник, который является публичным IP-адресом R1, и пункт назначения - публичный IP-адрес R2.
Как только мы завершим настройку R1, маршрутизатор подтвердит создание туннеля и сообщит о его состоянии:
R1#
*May 21 16:33:27.321: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
Поскольку интерфейс Tunnel 0 является логическим интерфейсом, он останется включенным, даже если туннель GRE не настроен или не подключен на другом конце.
Далее мы должны создать интерфейс Tunnel 0 на R2:
R2(config)# interface Tunnel0
R2(config-if)# ip address 172.16.0.2 255.255.255.0
R2(config-if)# ip mtu 1400
R2(config-if)# ip tcp adjust-mss 1360
R2(config-if)# tunnel source 2.2.2.10
R2(config-if)# tunnel destination 1.1.1.10
Интерфейс туннеля R2 настроен с соответствующим IP-адресом источника и назначения туннеля. Как и в случае с R1, маршрутизатор R2 сообщит нам, что интерфейс Tunnel0 работает:
R2#
*May 21 16:45:30.442: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up
Маршрутизация сетей через туннель GRE
На этом этапе обе конечные точки туннеля готовы и могут «видеть» друг друга. Echo icmp от одного конца подтвердит это:
R1# ping 172.16.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
R1#
Опять же, этот результат означает, что две конечные точки туннеля могут видеть друг друга. Рабочие станции в любой сети по-прежнему не смогут достичь другой стороны, если на каждой конечной точке не установлен статический маршрут:
R1(config)# ip route 192.168.2.0 255.255.255.0 172.16.0.2
На R1 мы добавляем статический маршрут к удаленной сети 192.168.2.0/24 через 172.16.0.2, который является другим концом нашего туннеля GRE. Когда R1 получает пакет для сети 192.168.2.0, он теперь знает, что следующим переходом является 172.16.0.2, и поэтому отправит его через туннель.
Та же конфигурация должна быть повторена для R2:
R2(config)# ip route 192.168.1.0 255.255.255.0 172.16.0.1
Теперь обе сети могут свободно общаться друг с другом через туннель GRE.
Защита туннеля GRE с помощью IPSec
Как упоминалось ранее, GRE является протоколом инкапсуляции и не выполняет шифрование. Создание туннеля GRE точка-точка без какого-либо шифрования чрезвычайно рискованно, поскольку конфиденциальные данные могут быть легко извлечены из туннеля и просмотрены другими.
Для этого мы используем IPSec для добавления уровня шифрования и защиты туннеля GRE. Это обеспечивает нам необходимое шифрование военного уровня и спокойствие. Наш пример ниже охватывает режим туннеля GRE IPSec.
Настройка шифрования IPSec для туннеля GRE (GRE over IPSec)
Шифрование IPSec включает в себя два этапа для каждого маршрутизатора. Эти шаги:
Настройка ISAKMP (ISAKMP Phase 1)
Настройка IPSec (ISAKMP Phase 2)
Настройка ISAKMP (ISAKMP Phase 1)
IKE существует только для установления SA (Security Association) для IPsec. Прежде чем он сможет это сделать, IKE должен согласовать отношения SA (ISAKMP SA) с партнером.
Для начала, мы начнем работать над R1.
Первым шагом является настройка политики ISAKMP Phase 1:
R1(config)# crypto isakmp policy 1
R1(config-isakmp)# encr 3des
R1(config-isakmp)# hash md5
R1(config-isakmp)# authentication pre-share
R1(config-isakmp)# group 2
R1(config-isakmp)# lifetime 86400
Приведенные выше команды определяют следующее (в указанном порядке):
3DES - метод шифрования, который будет использоваться на этапе 1 Phase 1
MD5 - алгоритм хеширования
Authentication pre-share - использование предварительного общего ключа в качестве метода проверки подлинности
Group 2 - группа Диффи-Хеллмана, которая будет использоваться
86400 - время жизни ключа сеанса. Выражается в килобайтах или в секундах. Значение установлено по умолчанию.
Далее мы собираемся определить Pre Shared Key (PSK) для аутентификации с партнером R1, 2.2.2.10:
R1(config)# crypto isakmp key merionet address 2.2.2.10
PSK ключ партнера установлен на merionet. Этот ключ будет использоваться для всех переговоров ISAKMP с партнером 2.2.2.10 (R2).
Создание IPSec Transform (ISAKMP Phase 2 policy)
Теперь нам нужно создать набор преобразований, используемый для защиты наших данных. Мы назвали это TS:
R1(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac
R1(cfg-crypto-trans)# mode transport
Вышеуказанные команды определяют следующее:
SP-3DES - метод шифрования
MD5 - алгоритм хеширования
Установите IPSec в транспортный режим.
Наконец, мы создаем профиль IPSec для соединения ранее определенной конфигурации ISAKMP и IPSec. Мы назвали наш профиль IPSec protect-gre:
R1(config)# crypto ipsec profile protect-gre
R1(ipsec-profile)# set security-association lifetime seconds 86400
R1(ipsec-profile)# set transform-set TS
Теперь мы готовы применить шифрование IPSec к интерфейсу туннеля:
R1(config)# interface Tunnel 0
R1(config-if)# tunnel protection ipsec profile protect-gre
Ну и наконец пришло время применить ту же конфигурацию на R2:
R2(config)# crypto isakmp policy 1
R2(config-isakmp)# encr 3des
R2(config-isakmp)# hash md5
R2(config-isakmp)# authentication pre-share
R2(config-isakmp)# group 2
R2(config-isakmp)# lifetime 86400
R2(config)# crypto isakmp key merionet address 1.1.1.10
R2(config)# crypto ipsec transform-set TS esp-3des esp-md5-hmac
R2(cfg-crypto-trans)# mode transport
R2(config)# crypto ipsec profile protect-gre
R2(ipsec-profile)# set security-association lifetime seconds 86400
R2(ipsec-profile)# set transform-set TS
R2(config)# interface Tunnel 0
R2(config-if)# tunnel protection ipsec profile protect-gre
Проверка GRE over IPSec туннеля
Наконец, наш туннель был зашифрован с помощью IPSec, предоставляя нам столь необходимый уровень безопасности. Чтобы проверить и проверить это, все, что требуется, это попинговать другой конец и заставить туннель VPN IPSec подойти и начать шифрование/дешифрование наших данных:
R1# ping 192.168.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
Используя команду show crypto session, мы можем быстро убедиться, что шифрование установлено и выполняет свою работу:
R1# show crypto session
Crypto session current status
Interface: Tunnel0
Session status: UP-ACTIVE
Peer: 2.2.2.10 port 500
IKE SA: local 1.1.1.10/500 remote 2.2.2.10/500 Active
IPSEC FLOW: permit 47 host 1.1.1.10 host 2.2.2.10
Active SAs: 2, origin: crypto map
Поздравляю! Мы только что успешно создали Point-to-point GRE over IPSec VPN туннель между двумя маршрутизаторами Cisco.
Доброго времени суток, уважаемый читатель! Сегодня постараемся дать ответ на очень частый у системных администраторов вопрос: как выбрать правильный VoIP шлюз для подключения Asterisk? Какой нужен шлюз для конкретной конфигурации и как выбрать между FXO, FXS, BRI и PRI. Разбираться будем на примере следующих сценариев:
Подключение IP – АТС Asterisk к ТфОП
На примере ISDN линии
Подключение через аналоговую линию
Подключение аналоговых устройств к Asterisk
Подключение обычной АТС и Asterisk к ISDN и аналоговой линии одновременно
Подключение обычной АТС к SIP - провайдеру
Подключение IP – АТС Asterisk к ТфОП
В данном примере у нас есть IP – АТС Asterisk и устойчивое желание подключить ее к ТфОП (Телефонная сеть общего пользования). Разберем два случая: подключение через ISDN и через обычный аналог.
На примере ISDN линии
Для начала разберемся с терминологией. ISDN (Integrated Services Digital Network) – цифровая сеть с интеграцией услуг (позволяет использование телефон, факса, обмен данными и прочие) имеет два типа подключения: BRI и PRI:
PRI (primary rate interface) – интерфейс первичного уровня. В России и Европе представлен потоком Е1, который имеет 32 канала, в котором 30 отведены на передачу голосу, а 2 остальных это сигнальные каналы. В России Е1 так же именуется ИКМ-30 (импульсно – кодовая модуляция, 30 каналов передачи). В США данный тип называется Т1.
Для простоты, обозначим, что Е1 PRI позволяет совершать 30 одновременных вызовов.
BRI (basic rate interface) – интерфейс базовой скорости. Основное различие состоит в том, что BRI предоставляет всего 3 канала, 2 из которых предназначены для передачи данных со скоростью 64 кбит/с, а 3 канал существует для передачи сигнальной информации. Для более простого понимания, запомним, что BRI позволяет совершать 2 одновременных вызова.
На выбор того, или иного подключения может повлиять количество одновременных вызовов у вас в организации. Например, вы совершаете максимум 6 одновременных вызовов. В данном случае вам нужно 3 BRI линии, и, соответственно для подключения к ним 3 портовый BRI шлюз. В другом примере, если вы совершаете максимум 28 одновременных вызовов, то рассмотрите PRI линию и соответствующий к ней PRI шлюз.
Интерфейс ISDN образуется всегда образуется между двумя типами оборудования:
TE (Terminal Equipment) – терминальное оборудование пользователя. Это может быть компьютер, рабочая станция, телефонные аппараты, ISDN – совместимый маршрутизатор и прочее совместимое оборудование, которое может быть установлено у конечных пользователей.
NR (Network Termination) – так называемое «сетевое окончание». Это конец линии, который подключается в ISDN коммутатор, завершая канал связи.
Теперь, когда мы обладаем необходимым «бэкграундом» для понимания принципов работы ISDN, схематично изобразим подключение Asterisk к ISDN через шлюз:
Вот небольшой список неплохих E1 PRI шлюзов:
Модель
Количество портов Е1
Примерная стоимость
Dinstar MTG200-1E1
1
1000 USD
Sangoma A101 1xE1
1
1500 USD
Yeastar NeoGate TE100
1
1050 USD
Beronet 1xE1, Box
1
1700 USD
Подключение через аналоговую линию
При подключении IP – АТС Asterisk через аналоговую линию все весьма тривиально – вам нужен обычный FXO шлюз. Одна аналоговая линия позволяет совершать 1 одновременный вызов. Схема соединения приведена ниже:
Ниже небольшой список совместимых с Asterisk FXO – шлюзов:
Модель
Количество FXO портов
Примерная стоимость
Dinstar DAG1000-4O
4
180 USD
Yeastar Neogate TA410
4
200 USD
D-Link DVG-7111S
1
50 USD
Grandstream GXW-4104
4
250 USD
Подключение аналоговых устройств к Asterisk
Теперь давайте разберем вариант, когда необходимо подключить аналоговое устройство к IP – АТС Asterisk. Это может быть простой аналоговый телефон или, например, факс. В данной конфигурации вам нужен FXS шлюз. Подключение одного устройства осуществляется в один порт FXS шлюза. Схема подключения приведена ниже:
Если вы находитесь в состоянии выбора FXS – шлюза, то обратите внимание на эти модели:
Модель
Количество FXS портов
Примерная стоимость
Audiocodes MP-114, 4FXS
4
600 USD
Dinstar DAG1000-4S
4
150 USD
Grandstream HT-704
4
120 USD
Yeastar Neogate TA800
8
230 USD
Подключение обычной АТС и Asterisk к ISDN и аналоговой линии одновременно
Рассмотрим весьма интересный сценарий: в нашем корпоративном контуре существует обычная офисная АТС и IP –АТС на базе Asterisk. К ТфОП они подключены через ISDN линию по интерфейсу E1 PRI.
В данном случае необходимо осуществить подключение обычной АТС по Е1 потоку до PRI шлюза, а так же, подключить IP – АТС по протоколу SIP к этому же шлюзу. Изобразим наглядно на схеме:
Подходящие для этой конфигурации модели:
Модель
Количество E1 портов
Примерная стоимость
Dinstar MTG200-2E1
2
1500 USD
Beronet 4xE1, Box
4
4300 USD
Теперь взглянем на подключение обычной АТС и IP – АТС Asterisk через аналог. Нам понадобится шлюз, оснащенный FXS и FXO портами. Учтите, что аналоговая линия позволяет совершать только 1 одновременный вызов, поэтому, выберите шлюз с достаточном количеством портов. Схема работы будет следующая:
Ну и конечно оборудование:
Модель
Количество FXO портов
Количество FXS портов
Примерная стоимость
Audiocodes MP-114, 2FXO/2FXS
2
2
650 USD
Dinstar DAG1000-4S4O
4
4
300 USD
Dinstar DAG2000-8S8O
8
8
500 USD
Подключение обычной АТС к SIP - провайдеру
Итак, осталось с разобраться с подключением обычной офисной АТС к SIP – провайдеру. В данном случае мы будем выбирать лишь как подключить АТС к шлюзу: через ISDN(PRI или BRI) или через аналог. За шлюзом у нас будет осуществляться подключение через сеть интернет по протоколу SIP. Соответственно, нужно также принять решение, будет это PRI – шлюз, или FXS – шлюз. Схема подключения АТС к SIP провайдеру через Е1 поток приведена ниже:
И соответственно схема для подключения АТС через аналог до шлюза:
Первая часть статьи доступна по ссылке: Базовая настройка коммутатора 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 в данный момент подключен к коммутатору.