license modify priority SSL_VPN high

Небольшая инструкция по настройке SSL VPN на маршрутизаторе Cisco.

Использовать будем след. оборудование:

Cisco 881 (C880DATA-UNIVERSALK9-M 15.2(4)M4)

Windows 7 x64 + AnyConnect 4.4

Схема подключения:

Для начала, что такое SSL VPN (или WEBVPN) от Cisco, это своего рода наследник easy vpn или ipsec vpn, который позволяет по протоколу ssl (https,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 режиме:

после чего соглашаемся с лицензионным соглашением.

2. Далее копируем дистрибутив any connect на роутер любым удобным способом(копирование лучше производить в заранее созданную диреторию webvpn, так как если просто скопировать в корень flash, то при установке циска создаст копию файла установки в ту же диреторию, соответственно займет больше места на флеше) и устанавливаем его.

mkdir flash:/webvpn

copy tftp: flash:/webvpn/

crypto vpn anyconnect flash:/webvpn/anyconnect-win-4.4.00243-k9.pkg

3. Включаем aaa (необходим чтобы указать authentication list, на нашем Web шлюзе (webvpn gateway)), заводим локальных пользователей (логин и пароль, которые здесь указываем необходимы для подключения к порталу из интернета, по типу https://внешнийадресроутера) и активируем https сервер

aaa new-model

aaa authentication login SSL_USERS local

username admin secret ***************

ip http secure-server

4. Генерируем RSA ключи, создаем trustpoint и затем генерируем самоподписанный сертификат

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_POLICY

8. Если у нас на внешнем интерфесе висит ACL, то необходимо дописать правило:

permit tcp any host «внешний адрес роутера» eq 443

В итоге запускаем на нашем клиенте браузер и вводим адрес нашего роутера https://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

И все работает!

Познавательные статьи:



Где возникла философия и почему?

Относительная высота сжатой зоны бетона

Сущность проекции Гаусса-Крюгера и использование ее в геодезии

Тарифы на перевозку пассажиров