В тази статия бих искал да предоставя инструкции стъпка по стъпка за това как можете бързо да внедрите най-мащабируемата схема в момента. VPN за отдалечен достъп базов достъп AnyConnect и Cisco ASA - VPN клъстер за балансиране на натоварването.
Въведение: Много компании по света, с оглед на настоящата ситуация с COVID-19, полагат усилия да прехвърлят своите служители на дистанционна работа. Поради масовия преход към дистанционна работа, натоварването на съществуващите VPN шлюзове на компаниите нараства критично и е необходима много бърза възможност за тяхното мащабиране. От друга страна, много компании са принудени набързо да овладеят концепцията за дистанционна работа от нулата.
За да помогне на бизнеса да постигне удобен, сигурен и мащабируем VPN достъп за служителите за възможно най-кратко време, Cisco лицензира богатия на функции SSL VPN клиент AnyConnect за до 13 седмици. .
.
Подготвих ръководство стъпка по стъпка за просто внедряване на VPN Load-Balancing Cluster като най-мащабируемата VPN технология.
Примерът по-долу ще бъде доста прост по отношение на използваните алгоритми за удостоверяване и оторизация, но ще бъде добър вариант за бърз старт (което в момента не е достатъчно за мнозина) с възможност за задълбочено адаптиране към вашите нужди по време на внедряването процес.
Кратка информация: Технологията на VPN Load Balancing Cluster не е отказоустойчива и не е функция за клъстериране в естествения си смисъл, тази технология може да комбинира напълно различни ASA модели (с определени ограничения), за да балансира натоварването на VPN връзките с отдалечен достъп. Няма синхронизация на сесиите и конфигурациите между възлите на такъв клъстер, но е възможно автоматично да се балансират натоварванията на VPN връзките и да се осигури устойчивост на грешки на VPN връзките, докато в клъстера остане поне един активен възел. Натоварването в клъстера се балансира автоматично в зависимост от натоварването на възлите по броя на VPN сесиите.
За прехвърляне на специфични възли на клъстера (ако е необходимо) може да се използва файл, така че активната връзка ще се обработва от основния възел на файла. Прехвърлянето на файлове не е необходимо условие за осигуряване на толерантност към грешки в клъстера за балансиране на натоварването, самият клъстер, в случай на повреда на възел, ще прехвърли потребителската сесия към друг жив възел, но без да запазва състоянието на връзката, което е точно предоставени от подателя. Съответно е възможно, ако е необходимо, да се комбинират тези две технологии.
Един VPN клъстер за балансиране на натоварването може да съдържа повече от два възела.
VPN Load-Balancing Cluster се поддържа от ASA 5512-X и по-нови.
Тъй като всеки ASA в рамките на клъстера за балансиране на натоварването на VPN е независима единица по отношение на настройките, ние извършваме всички стъпки за конфигуриране поотделно на всяко отделно устройство.
Логическата топология на дадения пример:
Първично внедряване:
-
Разполагаме ASAv екземпляри на шаблоните, от които се нуждаем (ASAv5/10/30/50) от изображението.
-
Ние присвояваме интерфейсите INSIDE / OUTSIDE към едни и същи VLAN (отвън в своя собствена VLAN, INSIDE в своя собствена, но като цяло в рамките на клъстера, вижте топологията), важно е интерфейсите от същия тип да са в един и същ L2 сегмент.
-
Лицензи:
- В момента инсталацията на ASAv няма да има никакви лицензи и ще бъде ограничена до 100kbps.
- За да инсталирате лиценз, трябва да генерирате токен във вашия Smart-акаунт: -> Интелигентно лицензиране на софтуер
- В прозореца, който се отваря, щракнете върху бутона Нов токен
- Уверете се, че в прозореца, който се отваря, има активно поле и има отметка Разрешете функционалност, контролирана от експортиране… Без това поле да е активно, няма да можете да използвате функциите на силно криптиране и съответно VPN. Ако това поле не е активно, моля, свържете се с екипа на вашия акаунт със заявка за активиране.
- След натискане на бутона Създаване на токен, ще бъде създаден токен, който ще използваме за получаване на лиценз за ASAv, копирайте го:
- Повторете стъпки C, D, E за всеки разгърнат ASAv.
- За да улесним копирането на токена, нека временно разрешим telnet. Нека конфигурираме всеки ASA (примерът по-долу илюстрира настройките на ASA-1). telnet не работи с външен, ако наистина имате нужда от него, променете нивото на сигурност на 100 на външно, след което го върнете обратно.
! 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 сървър;
- Ние се свързваме по телнет с нашия 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 (synced), # master (unsynced), + selected, - candidate, ~ configured ! ! Установим конфигурацию нашей 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), ще ви трябва файл с Пакет за внедряване на централна станция В заглавието:
- Изтеглените файлове могат да бъдат качени, например, на FTP сървър и качени на всеки отделен ASA:
- Ние конфигурираме ASDM и самоподписан сертификат за SSL-VPN (препоръчително е да използвате доверен сертификат в производството). Зададеното FQDN на адреса на виртуалния клъстер (vpn-demo.ashes.cc), както и всяко FQDN, свързано с външния адрес на всеки възел на клъстера, трябва да разреши във външната DNS зона до IP адреса на интерфейса OUTSIDE (или към съпоставения адрес, ако се използва препращане на порт 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 % The fully-qualified domain name in the certificate will be: vpn-demo.ashes.cc Generate Self-Signed Certificate? [yes/no]: yes vpn-demo-1(config)# ! vpn-demo-1(config)# sh cry ca certificates Certificate Status: Available Certificate Serial Number: 4d43725e Certificate Usage: General Purpose Public Key Type: RSA (4096 bits) Signature Algorithm: SHA256 with RSA Encryption Issuer Name: serialNumber=9A439T02F95 hostname=vpn-demo.ashes.cc cn=*.ashes.cc ou=ashes-lab o=ashes c=ru Subject Name: serialNumber=9A439T02F95 hostname=vpn-demo.ashes.cc cn=*.ashes.cc ou=ashes-lab o=ashes c=ru Validity Date: start date: 00:16:17 MSK Mar 19 2020 end date: 00:16:17 MSK Mar 17 2030 Storage: config Associated Trustpoints: SELF CA Certificate Status: Available Certificate Serial Number: 0509 Certificate Usage: General Purpose Public Key Type: RSA (4096 bits) Signature Algorithm: SHA1 with RSA Encryption Issuer Name: cn=QuoVadis Root CA 2 o=QuoVadis Limited c=BM Subject Name: cn=QuoVadis Root CA 2 o=QuoVadis Limited c=BM Validity Date: start date: 21:27:00 MSK Nov 24 2006 end date: 21:23:33 MSK Nov 24 2031 Storage: config Associated Trustpoints: _SmartCallHome_ServerCA- Не забравяйте да посочите порта, за да проверите дали ASDM работи, например:
- Нека да извършим основните настройки на тунела:
- Нека направим корпоративната мрежа достъпна през тунела и нека интернет да отиде директно (не е най-сигурният метод, ако няма защити на свързващия хост, възможно е да проникнете през заразен хост и да покажете корпоративни данни, опция split-tunnel-policy tunnelall ще пусне целия трафик на хост в тунела. въпреки това разделен тунел прави възможно разтоварването на VPN шлюза и не обработва интернет трафика на хоста)
- Нека издадем адреси от подмрежата 192.168.20.0/24 на хостове в тунела (пул от 10 до 30 адреса (за възел #1)). Всеки възел на VPN клъстера трябва да има собствен пул.
- Ние ще извършим основно удостоверяване с локално създаден потребител на ASA (Това не се препоръчва, това е най-лесният метод), по-добре е да направите удостоверяване чрез LDAP/РАДИУС, или още по-добре, вратовръзка Многофакторно удостоверяване (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 !- (НЕЗАДЪЛЖИТЕЛНО): В горния пример използвахме локален потребител в ITU за удостоверяване на отдалечени потребители, което разбира се, освен в лабораторията, е слабо приложимо. Ще дам пример как бързо да адаптирате настройката за удостоверяване 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 шлюз:
-
Нека да преминем към конфигурирането на клъстера за балансиране на натоварването.
Адресът 192.168.31.40 ще се използва като виртуален IP (VIP - всички VPN клиенти първоначално ще се свържат с него), от този адрес главният клъстер ще направи ПРЕНАСОЧВАНЕ към по-малко натоварен клъстерен възел. Не забравяйте да пишете напред и назад 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, така че ако трябва да се свържете, просто го изберете от списъка:
Тъй като създадохме този профил само на един ASA с помощта на ASDM, не забравяйте да повторите стъпките на другите ASA в клъстера.
Заключение: По този начин ние бързо внедрихме клъстер от няколко VPN шлюза с автоматично балансиране на натоварването. Добавянето на нови възли към клъстера е лесно, с просто хоризонтално мащабиране чрез внедряване на нови ASAv виртуални машини или използване на хардуерни ASA. Богатият на функции клиент AnyConnect може значително да подобри защитената отдалечена връзка чрез използване на Поза (оценки на състоянието), най-ефективно използван във връзка със системата за централизиран контрол и отчитане на достъпа Двигател за услуги за идентичност.
Източник: www.habr.com