In questo articolo, vorrei fornire una guida passo passo su come implementare rapidamente l'attuale schema di accesso più scalabile Remote-Access VPN basato su AnyConnect e Cisco ASA – VPN Load Balancing Cluster.
Introduzione: Molte aziende in tutto il mondo, a causa della situazione attuale con il COVID-19, stanno facendo sforzi per trasferire i propri dipendenti a modalità di lavoro remoto. A causa della massiccia transizione al lavoro a distanza, la pressione sui gateway VPN esistenti delle aziende aumenta drasticamente e si richiede una possibilità di scalabilità molto rapida. D'altro canto, molte aziende sono costrette a imparare in fretta il concetto di lavoro remoto.
Per aiutare le aziende a implementare nel minor tempo possibile un accesso VPN comodo, sicuro e scalabile per i dipendenti, Cisco offre licenze per il client SSL-VPN multifunzionale AnyConnect per un periodo di fino a 13 settimane. .
.
Ho preparato una guida passo passo per un'opzione semplice di distribuzione di un cluster VPN Load-Balancing come tecnologia VPN altamente scalabile.
L'esempio sottostante sarà piuttosto semplice in termini di algoritmi di autenticazione e autorizzazione impiegati, ma rappresenta una buona opzione per un avvio rapido (cosa che attualmente manca a molti) con la possibilità di un'adattamento approfondito alle proprie esigenze durante il processo di distribuzione.
Informazioni generali: La tecnologia del Cluster VPN Load Balancing non è failover né una funzione di clustering nel suo significato nativo; questa tecnologia permette di combinare modelli ASA completamente diversi (con alcune limitazioni) per bilanciare il carico delle connessioni VPN di accesso remoto. La sincronizzazione delle sessioni e delle configurazioni tra i nodi di tale cluster è assente, ma è possibile un bilanciamento automatico del carico delle connessioni VPN e garantire la resilienza delle connessioni VPN finché c'è almeno un nodo attivo nel cluster. Il carico nel cluster viene bilanciato automaticamente in base al numero di sessioni VPN attive sui nodi.
Per garantire la tolleranza ai guasti per nodi specifici del cluster (se necessario) è possibile utilizzare un file server, in questo modo la connessione attiva sarà gestita dal nodo primario del file server. Il file server non è un requisito necessario per garantire la tolleranza ai guasti all'interno di un cluster di Load-Balancing; il cluster stesso, in caso di guasto di un nodo, trasferirà la sessione utente su un altro nodo attivo, ma senza mantenere lo stato della connessione, cosa che viene garantita dal file server. Pertanto, è possibile combinare queste due tecnologie se necessario.
Un cluster VPN Load-Balancing può contenere più di due nodi.
Il cluster VPN Load-Balancing è supportato su ASA 5512-X e superiore.
Poiché ogni ASA all'interno del cluster VPN Load-Balancing è un'unità indipendente per quanto riguarda le impostazioni effettuate, tutte le fasi di configurazione vengono eseguite individualmente su ciascun dispositivo.
La topologia logica dell'esempio fornito:
Distribuzione iniziale:
Distribuiamo le istanze ASAv dai template di cui abbiamo bisogno (ASAv5/10/30/50).
Assegniamo le interfacce INSIDE/OUTSIDE agli stessi VLAN (Outside nel proprio VLAN, INSIDE nel proprio, ma comune all'interno del cluster, vedere la topologia), è importante che le interfacce dello stesso tipo si trovino nello stesso segmento L2.
Licenze:
- Al momento dell'installazione, l'ASAv non avrà alcuna licenza e sarà limitata a una performance di 100 kbit/sec.
- Per installare la licenza, è necessario generare un token nel proprio Smart Account: -> Smart Software Licensing
- Nella finestra che si apre, cliccare sul pulsante New Token
- Assicurati che nella finestra aperta ci sia il campo attivo e che sia selezionata l'opzione Allow export-controlled functionality… Senza questo campo attivo non sarà possibile utilizzare le funzionalità di crittografia avanzata e, di conseguenza, VPN. Se questo campo non è attivo, ti preghiamo di contattare il tuo team account per attivarlo.
- Dopo aver premuto il pulsante Crea token, verrà creato un token che useremo per ottenere la licenza per ASAv, copiamolo:
- Ripetiamo i passi C, D, E per ogni ASAv distribuita.
- Per semplificare la copia del token, abilitiamo temporaneamente telnet. Configuriamo ogni ASA (l'esempio qui sotto illustra le impostazioni su ASA-1). Il telnet su outside non funziona, se necessario, cambia il livello di sicurezza a 100 su outside, poi riportalo indietro.
! 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 !- Per registrare il token nel cloud Smart-Account è necessario fornire accesso a Internet per l'ASA. .
In breve, l'ASA è necessario:
- accesso HTTPS a Internet;
- synchronizzazione dell'orario (preferibilmente tramite NTP);
- server DNS configurato;
- Accediamo tramite telnet ai nostri ASA e configuriamo le impostazioni per attivare la licenza tramite 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 ! ! Verifichiamo il funzionamento del 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: !!!!! ! ! Verifichiamo la sincronizzazione 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 (sincronizzato), # master (non sincronizzato), + selezionato, - candidato, ~ configurato ! ! Configuriamo la nostra ASAv per Smart-Licensing (secondo il tuo profilo, nel mio caso 100M per esempio) ! ciscoasa(config)# license smart ciscoasa(config-smart-lic)# feature tier standard ciscoasa(config-smart-lic)# throughput level 100M ! ! Se necessario, puoi configurare l'accesso a Internet tramite proxy utilizzando il seguente blocco di comandi: !call-home ! http-proxy ip_address port port ! ! Successivamente, inseriamo il token copiato dal portale Smart-Account (<token>) e registriamo la licenza ! ciscoasa(config)# end ciscoasa# license smart register idtoken <token>- Verifichiamo che il dispositivo abbia registrato con successo la licenza e che le opzioni di crittografia siano disponibili:
Configuriamo un SSL-VPN di base su ciascun gateway.
- Successivamente, configuriamo l'accesso tramite SSH e 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 ! ! Configuriamo il server HTTPS per ASDM sulla porta 445 per non sovrapporsi al portale SSL-VPN ! vpn-demo-1(config)# http server enable 445 !- Per utilizzare ASDM è necessario prima scaricarlo dal sito cisco.com, nel mio caso si tratta del seguente file:
- Per il funzionamento del client AnyConnect è necessario caricare su ogni ASA l'immagine per ciascun sistema operativo desktop del client (previsto per Linux/Windows/MAC) sarà necessario un file con Pacchetto di distribuzione Headend nel nome:
- I file scaricati possono essere caricati, ad esempio, su un server FTP e caricati su ogni singola ASA:
- Configuriamo ASDM e il certificato self-signed per SSL-VPN (in produzione si consiglia di utilizzare un certificato attendibile). Il FQDN installato dell'indirizzo virtuale del cluster (vpn-demo.ashes.cc), insieme a ogni FQDN associato all'indirizzo esterno di ogni nodo del cluster, deve risolversi nella zona DNS esterna all'indirizzo IP dell'interfaccia OUTSIDE (o all'indirizzo mappato, se viene utilizzata la port forwarding udp/443 (DTLS) e tcp/443 (TLS)). Ulteriori informazioni sui requisiti per il certificato sono disponibili nella sezione Verifica del certificato documentazione.
! 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=it 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 % Il nome di dominio completamente qualificato nel certificato sarà: vpn-demo.ashes.cc Generare certificato auto-firmato? [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=it Subject Name: serialNumber=9A439T02F95 hostname=vpn-demo.ashes.cc cn=*.ashes.cc ou=ashes-lab o=ashes c=it 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- Per verificare il funzionamento dell'ASDM, ricordate di specificare la porta, ad esempio:
- Procederemo con le configurazioni base del tunnel:
- Rendere accessibile la rete aziendale tramite un tunnel, mentre l'accesso a Internet avviene direttamente (non è il metodo più sicuro in assenza di misure di protezione sul host connesso, c'è il rischio di infiltrazione tramite un host infetto e di esposizione dei dati aziendali, opzione split-tunnel-policy tunnelall invierà tutto il traffico dell'host nel tunnel. Tuttavia, Split-Tunnel consente di alleggerire il gateway VPN e di non elaborare il traffico Internet dell'host)
- Assegneremo agli host nel tunnel indirizzi dalla sottorete 192.168.20.0/24 (pool dagli indirizzi 10 al 30 (per il nodo #1)). Ogni nodo del cluster VPN deve avere il proprio pool.
- Effettueremo un'autenticazione di base tramite un utente creato localmente su ASA (questo metodo non è raccomandato, è il più semplice), è meglio autenticarsi tramite LDAP/RADIUS, e ancor meglio legare l'Autenticazione a Fattore Multiplo (MFA), ad esempio 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 !- (OPZIONALE): Nell'esempio sopra, abbiamo utilizzato un utente locale su Cisco Identity Services Engine per autenticare gli utenti remoti, il che, ovviamente, è poco praticabile al di fuori di un laboratorio. Mostrerò un esempio di come adattare rapidamente la configurazione per l'autenticazione su RADIUS un server, utilizzando 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 !Questa integrazione ha reso possibile non solo un'integrazione rapida della procedura di autenticazione con il servizio directory AD, ma anche la distinzione dell'appartenenza del computer connesso all'AD, comprendendo se si tratta di un dispositivo aziendale o personale e valutando lo stato del dispositivo collegato.
- Configuriamo il Transparent NAT affinché il traffico tra il cliente e le risorse della rete aziendale non venga NATtato:
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- (OPZIONALE): Per consentire ai nostri clienti di accedere a Internet tramite ASA (utilizzando tunnelall opzioni) utilizzando PAT, e uscire attraverso lo stesso interfaccia OUTSIDE da cui si connettono, è necessario apportare le seguenti configurazioni:
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 !- È estremamente importante, quando si utilizza un cluster, consentire alla rete interna di comprendere verso quale ASA instradare il traffico di ritorno agli utenti; è necessario effettuare una ridistribuzione delle rotte /32 assegnate ai clienti.
Attualmente non abbiamo ancora configurato il cluster, ma abbiamo già gateway VPN funzionanti a cui è possibile connettersi individualmente tramite FQDN o IP.
Possiamo vedere il cliente connesso nella tabella di routing della prima ASA:
Affinché l'intero cluster VPN e l'intera rete aziendale conoscano il percorso verso il nostro cliente, eseguiremo la ridistribuzione del prefisso clienti nel protocollo di routing dinamico, ad esempio 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-REDISTRIBUTEOra abbiamo un percorso verso il cliente dal secondo gateway ASA-2 e gli utenti connessi a diversi gateway VPN all'interno del cluster possono, ad esempio, comunicare tramite il softphone aziendale direttamente, così come il traffico di ritorno delle risorse richieste dall'utente arriverà al gateway VPN corretto:
Passiamo alla configurazione del cluster di bilanciamento del carico.
L'indirizzo 192.168.31.40 verrà utilizzato come IP Virtuale (VIP — a cui si connetteranno inizialmente tutti i client VPN), da questo indirizzo il Master del cluster eseguirà un REDIRECT verso il nodo del cluster meno carico. Non dimenticare di definire la registrazione DNS diretta e inversa sia per ogni indirizzo esterno/FQDN di ciascun nodo del cluster, che per il 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)#- Verifichiamo il funzionamento del cluster con due client connessi:
- Rendere l'esperienza del cliente più comoda con il profilo AnyConnect caricato automaticamente tramite ASDM.
Nominiamo il profilo in modo conveniente e associamo la nostra politica di gruppo ad esso:
Dopo la prossima connessione del cliente, questo profilo verrà automaticamente scaricato e installato nel client AnyConnect, permettendo di sceglierlo facilmente dalla lista se necessario:
Poiché, utilizzando ASDM, abbiamo creato questo profilo solo su un'ASA, non dimenticare di ripetere l'operazione sulle altre ASA del cluster.
Risultato: In questo modo, abbiamo implementato rapidamente un cluster di più gateway VPN con bilanciamento del carico automatico. Aggiungere nuove nodi al cluster è semplice, ottenendo una scalabilità orizzontale tramite il deployment di nuove macchine virtuali ASAv o l'uso di ASA hardware. Il versatile client AnyConnect può ampliare notevolmente le possibilità di connessione remota sicura utilizzando la funzionalità Posture (valutazione dello stato), particolarmente efficace se utilizzata insieme al sistema di controllo centralizzato e gestione degli accessi Identity Services Engine.
Fonte: habr.com
