Приветствую, коллеги, хотелось бы описать шаги настройки SSL VPN для Cisco, с описанием некоторых интересных нюансов, встречаемых на практике.
Для реализации схемы, показанной ниже, будем использовать следующее реальное физическое оборудование, также прошу заметить что названия интерфейсов условны и в реализации не применяются (реализовать ssl vpn в unl-eve не удалось, так как ни iol ни vios команды для конфигурирования webvpn не поддерживают):
Cisco 881 (C880DATA-UNIVERSALK9-M 15.2(4)M4)
Windows 7 x64 + AnyConnect 4.4
Схема подключения:
Для начала, что такое SSL VPN (или WEBVPN) от Cisco. Это своего рода наследник easy vpn или ipsec vpn, который позволяет по протоколу ssl (443 порт) удаленно подключиться к вашей корпоративной или домашней сети. Кроме простоты настройки и относительно «легкого» конфига, самым большим доводом за использование ssl является то, что он использует практически повсеместно «открытый» 443 порт для подключения, т.е. если бы вы, например, использовали ipsec, то необходимо было бы на межсетевом экране или же на граничном роутере открывать isakmp (500) порты, наверняка разрешить nat-t (4500), и еще вдобавок разрешить трафик esp, тогда как в случае с ssl подключение проходит по 443 порту, который в большинстве своем разрешен для хостов. Кроме этого не надо на стороне клиента производить каких либо настроек, удаленному пользователю достаточно знать всего лишь внешний ip или dns имя роутера, а также логин и пароль для входа (при использовании easyvpn помимо вышеперечисленного нужен pre-share ключ, а также наименование client configuration group).
Настройка:
1. Для начала необходимо активировать лицензию на роутере, в нашем случае используется cisco 881 c ios 15.2(4), для ознакомительной активации на 60 дней вводим след. команду в privilege режиме:
license modify priority SSL_VPN highПосле чего соглашаемся с лицензионным соглашением.
2. Далее копируем дистрибутив any connect на роутер любым удобным способом(копирование лучше производить в заранее созданную директорию webvpn, так как если просто скопировать в корень flash, то при установке создастся копия файла установки в той же директории, соответственно займет больше места на flash) и устанавливаем его:
mkdir flash:/webvpn
copy tftp: flash:/webvpn/
crypto vpn anyconnect flash:/webvpn/anyconnect-win-4.4.00243-k9.pkg3. Включаем aaa (необходим, чтобы указать authentication list на нашем Web шлюзе (webvpn gateway)), заводим локальных пользователей (логин и пароль, которые здесь указываем необходимы для подключения к порталу из интернета, по типу внешнийадресроутера) и активируем https сервер:
aaa new-model
aaa authentication login SSL_USERS local
username admin secret ***************
ip http secure-server4. Генерируем RSA ключи, создаем trustpoint и затем генерируем самоподписанный сертификат:
crypto key generate rsa label SSLKEY modulus 1024
crypto pki trustpoint SALAM_TRUSTPOINT
enrollment selfsigned
serial-number
subject-name CN=firewallcx-certificate
revocation-check crl
rsakeypair SSLKEY
crypto pki enroll SALAM_TRUSTPOINT5. Настраиваем пул адресов, который будет выдаваться клиентам и создаем WebVPN Gateway, для команды ip interface вместо интерфейса можно указать непосредственно ip адрес командой ip address **** port 443:
ip local pool WEBVPN_POOL 10.0.0.11 10.0.0.15
webvpn gateway WEBVPN_GW
ip interface Dialer1 port 443
ssl trustpoint SALAM_TRUSTPOINT
inservice6. Далее создаем и привязываем к нашему gateway так называемый webvpn context, в котором указаваем ранее созданный auth list, максимальное кол-во подключаемых пользователей, а также приветствие отображаемое при входе на портал через браузер(команда inservice в этом и предыдущем шаге активирует webvpn gateway и context):
webvpn context WEBVPN_CON
title "Assalyamu alyaikum"
login-message "Salyam"
aaa authentication list SSL_USERS
gateway WEBVPN_GW
max-users 5
inservice
7. Там же в конфигурации webvpn context создаем policy group, в которой задаем наш пул адресов, указываем какой трафик от клиентов будет заворачиваться в туннель (в нашем случае, когда destination у клиентов будут сети 192.168.1.0 /24 или 172.16.1.0/24 в таблице маршрутизации на клиентах появятся соответствующие записи только для этих двух сетей, указывающие на то, что этот трафик будет уходить в шифрованный туннель), команда functions svc-enabled указывает, что удаленный пользователь может подключаться с помощью самостоятельно установленного клиента anyconnect, т.е. не надо заходить через браузер:
policy group WEBVPN_POLICY
functions svc-enabled
svc address-pool "WEBVPN_POOL" netmask 255.255.255.0
svc split include 192.168.1.0 255.255.255.0
svc split include 172.16.1.0 255.255.255.0
default-group-policy WEBVPN_POLICY8. Если у нас на внешнем интерфейсе висит ACL, то необходимо дописать правило:
permit tcp any host «внешний адрес роутера» eq 443В итоге запускаем на нашем клиенте браузер, вводим внешний адрес нашего роутера 212.212.0.1 и видим приглашение:
Осталось ввести логин пароль и установить соединение, на этом бы все, но есть один нюанс.
Если обратиться к нашей схеме, то сеть 192.168.1.0/24, та самая к которой мы подключаемся, находится за NATом, настройка NAT для роутера R1 следующая:
ip nat inside source list NAT_POOL interface Dialer1 overloadгде NAT_POOL:
ip access-list extended NAT_POOL
permit ip 192.168.1.0 0.0.0.255 anyчто произойдет если мы будем пинговать сеть 192.168.1.0 с подключившегося по vpn клиента(клиент получил адрес 10.0.0.12)? Пакеты от него зашифрованными будут уходить на R1, тот в свою очередь создает ответ с destination 10.0.0.12 и смотрит в таблицу маршрутизации:
R1#sh ip route 10.0.0.12
Routing entry for 10.0.0.12/32
Known via "static", distance 0, metric 0
Routing Descriptor Blocks:
* directly connected, via Virtual-Access3
Route metric is 0, traffic share count is 1
R1#sh interfaces virtual-access 3
Virtual-Access3 is up, line protocol is up
Hardware is Virtual Access interface
Description: ***Internally created by SSLVPN context WEBVPN_CON***
Interface is unnumbered. Using address of Dialer1 (212.212.0.1)
MTU 1406 bytes, BW 100000 Kbit/sec, DLY 100000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation SSL
SSL vaccessТ.е. пакеты уходят с интерфейса dialer 1, а согласно вот этой замечательной таблице порядка операций над трафиком
после routing у нас идет NAT, а наше правило nat говорит нам, что наш source заменится на публичный адрес и в таком виде уйдет на клиента, который понятия не имеет о нашем внешнем адресе, следовательно пинг не пройдет и ничего работать не будет, исправляем добавлением следующей команды в acl NAT_POOL:
ip access-list extended NAT_POOL
1 deny ip 192.168.1.0 0.0.0.255 10.0.0.0 0.0.0.255И, альхьамдулиЛлях1, все работает!
Автор: xamzaibnm
