В настоящата статия искам да представя стъпка по стъпка ръководство как бързо да се разгърне най-мащабируемата схема в момента. Remote-Access VPN достъп на база AnyConnect и Cisco ASA – VPN Load Balancing Cluster.
Въведение: Много компании по целия свят, поради текущата ситуация с COVID-19, полагат усилия да преместят своите служители на дистанционен режим на работа. Поради масовия преход към дистанционна работа, натискът върху съществуващите VPN шлюзове на компаниите нараства критично и е необходима много бърза възможност за мащабиране. От друга страна, много компании са принудени в бързината да усвояват отначало понятието дистанционна работа.
За да помогне на бизнеса да реализира в кратки срокове удобен, безопасен и мащабируем VPN достъп за служителите, компания Cisco предлага лицензии за многофункционалния SSL-VPN клиент AnyConnect за срок до 13 седмици. .
.
Подготвих стъпка по стъпка инструкция за прост вариант на разгръщане на VPN Load-Balancing клъстер, като най-мащабируемата технология за VPN.
Посоченият пример ще бъде доста прост от гледна точка на използваните алгоритми за автентикация и авторизация, но ще бъде добър вариант за бърз старт (което в момента много хора нямат) с възможност за дълбочинна адаптация според собствените нужди по време на разгръщането.
Кратки сведения: Технологията VPN Load Balancing Cluster не е failover и не е функция на клъстеризация в нейното нативно разбиране; с тази технология могат да се обединяват абсолютно различни модели ASA (с определени ограничения) с цел балансиране на натоварването на Remote-Access VPN сесии. Синхронизацията на сесиите и конфигурациите между възлите на такъв клъстер липсва, но възможно е автоматично балансиране на натоварването на VPN сесиите и осигуряване на отказоустойчивост на VPN връзките, докато остане поне един активен възел в клъстера. Натоварването в клъстера се балансира автоматично в зависимост от натовареността на възлите по брой VPN сесии.
За отказоустойчивост на конкретни възли на клъстера (ако е необходимо) може да се прилага файловер, така активната връзка ще бъде обработвана от основния възел на файловера. Файловерът не е задължително условие за осигуряване на отказоустойчивост в рамките на Load-Balancing клъстера; самият клъстер в случай на отказ на възел ще прехвърли сесията на потребителя на друг работещ възел, но без запазване на статуса на връзката, което точно се осигурява от файловера. Съответно може да се комбинират тези две технологии при необходимост.
VPN Load-Balancing клъстер може да съдържа повече от два възела.
VPN Load-Balancing клъстер се поддържа на ASA 5512-X и нагоре.
Тъй като всяка ASA в рамките на VPN Load-Balancing клъстера е независима единица от гледна точка на извършваните настройки, всички етапи на конфигуриране извършваме индивидуално на всяко отделно устройство.
Логическата топология на предоставения пример:
Първично разгръщане:
Разгръщаме от образа инстанции ASAv на нужните ни шаблони (ASAv5/10/30/50).
Назначаваме интерфейси INSIDE/OUTSIDE на еднакви VLAN (Outside в своя VLAN, INSIDE в своя, но общ в рамките на клъстера; вижте топологията), важно е да имаме интерфейсите от един и същи тип в един L2 сегмент.
Лицензи:
- Към момента на инсталиране ASAv няма да има никакви лицензии и ще бъде ограничена до производителност от 100кбит/сек.
- За инсталиране на лиценза е необходимо да генерирате токен в Вашия Smart-Account: -> Smart Software Licensing
- В отвореното прозорче натиснете бутона New Token
- Уверете се, че в отвореното прозорче има активно поле и е поставена отметка Allow export-controlled functionality… Без това активно поле не можете да използвате функции на силно криптиране и съответно VPN. Ако това поле не е активно, моля, свържете се с Вашия екип за подкрепа с искане за активиране.
- След натискване на бутона Create Token, ще бъде създаден токен, който ще използваме за получаване на лицензия за ASAv, копирайте го:
- Повторете стъпките C,D,E за всеки инсталиран ASAv.
- За да бъде по-лесно копирането на токена, временно ще разрешим telnet. Ще настроим всяка ASA (примерът по-долу илюстрира настройките на ASA-1). telnet от outside не работи; ако е наистина необходимо, сменете security-level на 100 на outside, след това го върнете обратно.
! ciscoasa(config)# int gi0/0 ciscoasa(config)# nameif outside ciscoasa(config)# ip address 192.168.31.30 255.255.255.0 ciscoasa(config)# no shut ! ciscoasa(config)# int gi0/1 ciscoasa(config)# nameif inside ciscoasa(config)# ip address 192.168.255.2 255.255.255.0 ciscoasa(config)# no shut ! ciscoasa(config)# telnet 0 0 inside ciscoasa(config)# username admin password cisco priv 15 ciscoasa(config)# ena password cisco ciscoasa(config)# aaa authentication telnet console LOCAL ! ciscoasa(config)# route outside 0 0 192.168.31.1 ! ciscoasa(config)# wr !- За да регистрирате токена в облака Smart-Account, е необходимо да предоставите достъп до Интернет за ASA, .
Кратко казано, ASA е необходим:
- достъп по HTTPS до Интернет;
- синхронизация на времето (по-добре чрез NTP);
- написан DNS сървър;
- Свързваме се по telnet с нашето ASA и правим настройки за активиране на лиценза чрез Smart-Account.
! ciscoasa(config)# clock set 19:21:00 Mar 18 2020 ciscoasa(config)# clock timezone MSK 3 ciscoasa(config)# ntp server 192.168.99.136 ! ciscoasa(config)# dns domain-lookup outside ciscoasa(config)# DNS server-group DefaultDNS ciscoasa(config-dns-server-group)# name-server 192.168.99.132 ! ! Проверяваме работата на DNS: ! ciscoasa(config-dns-server-group)# ping ya.ru Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 87.250.250.242, timeout is 2 seconds: !!!!! ! ! Проверяваме синхронизацията на NTP: ! ciscoasa(config)# show ntp associations address ref clock st when poll reach delay offset disp *~192.168.99.136 91.189.94.4 3 63 64 1 36.7 1.85 17.5 * master (синхронизиран), # master (несинхронизиран), + избран, - кандидат, ~ конфигуриран ! ! Установяваме конфигурацията на нашата ASAv за Smart-Licensing (в съответствие с Вашия профил, в моя случай 100М за пример) ! ciscoasa(config)# license smart ciscoasa(config-smart-lic)# feature tier standard ciscoasa(config-smart-lic)# throughput level 100M ! ! При необходимост можете да настроите достъп до Интернет през прокси, използвайте следния набор от команди: !call-home ! http-proxy ip_address port port ! ! След това публикуваме копирания от портала Smart-Account токен (<token>) и регистрираме лиценза ! ciscoasa(config)# end ciscoasa# license smart register idtoken <token>- Проверяваме дали устройството успешно е регистрирало лиценза и опцийте за криптиране са налични:
Настройваме основен SSL-VPN на всеки шлюз
- След това настройваме достъп чрез SSH и ASDM:
ciscoasa(config)# ssh ver 2 ciscoasa(config)# aaa authentication ssh console LOCAL ciscoasa(config)# aaa authentication http console LOCAL ciscoasa(config)# hostname vpn-demo-1 vpn-demo-1(config)# domain-name ashes.cc vpn-demo-1(config)# cry key gen rsa general-keys modulus 4096 vpn-demo-1(config)# ssh 0 0 inside vpn-demo-1(config)# http 0 0 inside ! ! Активираме HTTPS сървър за ASDM на порт 445, за да не се припокрива с SSL-VPN портала ! vpn-demo-1(config)# http server enable 445 !- За да работи ASDM, първо трябва да го изтеглите от сайта cisco.com, в моя случай това е следният файл:
- За работата на AnyConnect клиента е необходимо да се зареди образ на всяка ASA за всяка използвана десктоп ОС (планираната за използване Linux/Windows/MAC) ще е нужен файл с Пакет за внедряване на Headend в името на:
- Свалените файлове могат да бъдат поставени, например, на FTP сървър и да се качат на всяка отделна ASA:
- Настройваме ASDM и самоподписан сертификат за SSL-VPN (в продукция се препоръчва да се използва доверен сертификат). Установеният FQDN на виртуалния адрес на клъстера (vpn-demo.ashes.cc), както и всеки FQDN, свързан с външния адрес на всяка нода от клъстера, трябва да се разрешава във външната DNS зона на IP адреса на интерфейса OUTSIDE (или на mapped адрес, ако се използва пренасочване на порта udp/443 (DTLS) и tcp/443 (TLS)). Подробна информация за изискванията към сертификата е посочена в раздела Проверка на сертификата документацията.
! vpn-demo-1(config)# crypto ca trustpoint SELF vpn-demo-1(config-ca-trustpoint)# enrollment self vpn-demo-1(config-ca-trustpoint)# fqdn vpn-demo.ashes.cc vpn-demo-1(config-ca-trustpoint)# subject-name cn=*.ashes.cc, ou=ashes-lab, o=ashes, c=ru vpn-demo-1(config-ca-trustpoint)# serial-number vpn-demo-1(config-ca-trustpoint)# crl configure vpn-demo-1(config-ca-crl)# cry ca enroll SELF % Пълното домейн име в сертификата ще бъде: vpn-demo.ashes.cc Генерирано ли е самоподписан сертификат? [да/не]: да vpn-demo-1(config)# ! vpn-demo-1(config)# sh cry ca certificates Сертификат Статус: Наличен Сертификатен сериен номер: 4d43725e Използване на сертификат: Общо предназначение Тип на публичния ключ: RSA (4096 бита) Алгоритъм на подписване: SHA256 с RSA криптиране Име на издателя: serialNumber=9A439T02F95 hostname=vpn-demo.ashes.cc cn=*.ashes.cc ou=ashes-lab o=ashes c=ru Име на предмет: serialNumber=9A439T02F95 hostname=vpn-demo.ashes.cc cn=*.ashes.cc ou=ashes-lab o=ashes c=ru Дата на валидност: начална дата: 00:16:17 MSK 19 март 2020 крайна дата: 00:16:17 MSK 17 март 2030 Съхранение: конфигурация Свързани доверителни точки: SELF CA Сертификат Статус: Наличен Сертификатен сериен номер: 0509 Използване на сертификат: Общо предназначение Тип на публичния ключ: RSA (4096 бита) Алгоритъм на подписване: SHA1 с RSA криптиране Име на издателя: cn=QuoVadis Root CA 2 o=QuoVadis Limited c=BM Име на предмет: cn=QuoVadis Root CA 2 o=QuoVadis Limited c=BM Дата на валидност: начална дата: 21:27:00 MSK 24 ноември 2006 крайна дата: 21:23:33 MSK 24 ноември 2031 Съхранение: конфигурация Свързани доверителни точки: _SmartCallHome_ServerCA- За проверка на работата на ASDM не забравяйте да укажете порт, например:
- Ще направим основните настройки на тунела:
- Ще направим корпоративната мрежа достъпна през тунела, а интернет ще пропуснем директно (не е най-безопасният метод при отсъствие на защитни средства на свързания хост, е възможно проникване през заразен хост и извеждане на корп. данни, опцията split-tunnel-policy tunnelall ще пропусне целия трафик на хоста в тунела. Въпреки това, Split-Tunnel дава възможност за облекчаване на натоварването на VPN шлюза и не обработва трафика на интернет хоста)
- Ще раздадем на хостовете в тунела адреси от подсет 192.168.20.0/24 (обхват от 10 до 30 адреса (за нода #1)). На все възли на кластера VPN, пулът трябва да бъде собствен.
- Ще извършим основна автентикация с локално създаден потребител на ASA (това не се препоръчва, това е най-простият метод), по-добре е да извършите автентикация чрез LDAP/RADIUS, а още по-добре е да свържете Многофакторна автентикация (MFA), например Cisco DUO.
! vpn-demo-1(config)# ip local pool vpn-pool 192.168.20.10-192.168.20.30 mask 255.255.255.0 ! vpn-demo-1(config)# access-list split-tunnel standard permit 192.168.0.0 255.255.0.0 ! vpn-demo-1(config)# group-policy SSL-VPN-GROUP-POLICY internal vpn-demo-1(config)# group-policy SSL-VPN-GROUP-POLICY attributes vpn-demo-1(config-group-policy)# vpn-tunnel-protocol ssl-client vpn-demo-1(config-group-policy)# split-tunnel-policy tunnelspecified vpn-demo-1(config-group-policy)# split-tunnel-network-list value split-tunnel vpn-demo-1(config-group-policy)# dns-server value 192.168.99.132 vpn-demo-1(config-group-policy)# default-domain value ashes.cc vpn-demo-1(config)# tunnel-group DefaultWEBVPNGroup general-attributes vpn-demo-1(config-tunnel-general)# default-group-policy SSL-VPN-GROUP-POLICY vpn-demo-1(config-tunnel-general)# address-pool vpn-pool ! vpn-demo-1(config)# username dkazakov password cisco vpn-demo-1(config)# username dkazakov attributes vpn-demo-1(config-username)# service-type remote-access ! vpn-demo-1(config)# ssl trust-point SELF vpn-demo-1(config)# webvpn vpn-demo-1(config-webvpn)# enable outside vpn-demo-1(config-webvpn)# anyconnect image disk0:/anyconnect-win-4.8.03036-webdeploy-k9.pkg vpn-demo-1(config-webvpn)# anyconnect enable !- (ОПЦИОНАЛНО): В горния пример използвахме локален потребител на МСЕ за автентикация на отдалечени потребители, което, разбира се, извън лабораторията е слабо приложимо. Ще дам пример как бързо да адаптираме конфигурацията за автентикация на RADIUS сървър, за пример е използван Cisco Identity Services Engine:
vpn-demo-1(config-aaa-server-group)# dynamic-authorization vpn-demo-1(config-aaa-server-group)# interim-accounting-update vpn-demo-1(config-aaa-server-group)# aaa-server RADIUS (outside) host 192.168.99.134 vpn-demo-1(config-aaa-server-host)# key cisco vpn-demo-1(config-aaa-server-host)# exit vpn-demo-1(config)# tunnel-group DefaultWEBVPNGroup general-attributes vpn-demo-1(config-tunnel-general)# authentication-server-group RADIUS !Тази интеграция дава възможност не само бързо да се интегрира процедурата по автентикация със службата за директории AD, но и да се различава принадлежността на свързания компютър към AD, да се разбира дали е корпоративно устройство или личното, и да се оценява състоянието на свързаното устройство.
- Нека направим настройка на Transparent NAT, за да не се натоварва трафикът между клиента и ресурсите на корпоративната мрежа:
vpn-demo-1(config-network-object)# subnet 192.168.20.0 255.255.255.0 ! vpn-demo-1(config)# nat (inside,outside) source static any any destination static vpn-users vpn-users no-proxy-arp- (ОПЦИОНАЛНО): За да пуснем нашите клиенти в интернет през ASA (при използване tunnelall опции) с използването на PAT, а също така изходящите връзки през същия интерфейс OUTSIDE, от който се свързват, за целта трябва да направите следните настройки
vpn-demo-1(config-network-object)# nat (outside,outside) source dynamic vpn-users interface vpn-demo-1(config)# nat (inside,outside) source dynamic any interface vpn-demo-1(config)# same-security-traffic permit intra-interface !- Изключително важно при използването на клъстер да се позволи на вътрешната мрежа да разбере на коя ASA да маршрутизира обратния трафик към потребителите, за това е необходимо да направите ренаспределение на маршрутите /32 адреси, издавани на клиентите.
В момента клъстерът все още не е настроен, но вече имаме работещи VPN шлюзове, към които може да се свързвате индивидуално по FQDN или IP.
Ние виждаме свързания клиент в таблицата за маршрутизация на първата ASA:
За да знае целият наш VPN клъстер и цялата корпоративна мрежа маршрута до нашия клиент, ще проведем ренаспределение на клиентския префикс в протокола за динамично маршрутизиране, например OSPF:
! vpn-demo-1(config)# route-map RMAP-VPN-REDISTRIBUTE permit 1 vpn-demo-1(config-route-map)# match ip address VPN-REDISTRIBUTE ! vpn-demo-1(config)# router ospf 1 vpn-demo-1(config-router)# network 192.168.255.0 255.255.255.0 area 0 vpn-demo-1(config-router)# log-adj-changes vpn-demo-1(config-router)# redistribute static metric 5000 subnets route-map RMAP-VPN-REDISTRIBUTEСега имаме маршрут до клиента от втория шлюз ASA-2 и потребителите, свързани към различни VPN шлюзове в рамките на клъстера, могат, например, да комуникират чрез корпоративен софтуер директно, а също така обратният трафик от запрашените ресурси от потребителя ще идва на нужния VPN шлюз:
Преминаваме към настройката на Load-Balancing на клъстера.
Адрес 192.168.31.40 ще се използва като Virtual IP (VIP — към него ще се свързват всички VPN клиенти), от този адрес Master на клъстера ще направи REDIRECT към по-малко натоварен възел на клъстера. Не забравяйте да запишете правилната и обратната DNS записа както за всеки външен адрес/FQDN на всеки възел от клъстера, така и за VIP.
vpn-demo-1(config)# vpn load-balancing vpn-demo-1(config-load-balancing)# interface lbpublic outside vpn-demo-1(config-load-balancing)# interface lbprivate inside vpn-demo-1(config-load-balancing)# priority 10 vpn-demo-1(config-load-balancing)# cluster ip address 192.168.31.40 vpn-demo-1(config-load-balancing)# cluster port 4000 vpn-demo-1(config-load-balancing)# redirect-fqdn enable vpn-demo-1(config-load-balancing)# cluster key cisco vpn-demo-1(config-load-balancing)# cluster encryption vpn-demo-1(config-load-balancing)# cluster port 9023 vpn-demo-1(config-load-balancing)# participate vpn-demo-1(config-load-balancing)#- Проверяваме работата на клъстера с двама свързани клиенти:
- Нека направим клиентското преживяване по-удобно с автоматично зареждащия се профил AnyConnect чрез ASDM.
Наричаме профила по удобен начин и асоциираме груповата политика с него:
След следващото свързване на клиента, този профил ще бъде автоматично изтеглен и инсталиран в клиента AnyConnect, така че при необходимост просто да го изберем от списъка:
Тъй като, използвайки ASDM, създадохме този профил само на един ASA, не забравяйте да повторите действията на останалите ASA в клъстера.
Извод: По този начин бързо изградихме клъстер от няколко VPN шлюза с автоматично балансиране на натоварването. Добавянето на нови нодове към клъстера не е трудно, като получаваме прост хоризонтален мащаб, като разгръщаме нови виртуални машини ASAv или използваме хардуерни ASA. Многофункционалният клиент AnyConnect може значително да разшири възможностите за безопасно отдалечено свързване, използвайки функцията Posture (оценка на състоянието), най-ефективно прилагана съвместно със система за централизирано управление и контрол на достъпа Identity Services Engine.
Източник: habr.com
