In questo articolo vorrei fornire una guida passo-passo su come implementare rapidamente la più scalabile architettura disponibile al momento Remote-Access VPN accesso basato su AnyConnect e Cisco ASA – VPN Load Balancing Cluster.
Introduzione: Molte aziende in tutto il mondo, a causa dell'attuale situazione legata al COVID-19, stanno facendo sforzi per trasferire i propri dipendenti a un lavoro da remoto. A causa della massiccia transizione al lavoro remoto, si sta verificando un aumento critico del carico sui gateway VPN esistenti e c'è bisogno di una rapida capacità di scalabilità. D'altro canto, molte aziende si trovano costrette a imparare frettolosamente un concetto come il lavoro da remoto.
Per aiutare le aziende a implementare nel più breve tempo possibile un accesso VPN conveniente, sicuro e scalabile per i dipendenti, Cisco offre licenze per il client SSL-VPN multifunzionale AnyConnect fino a 13 settimane. .
.
Ho preparato una guida passo-passo per una semplice implementazione di un cluster di bilanciamento del carico VPN come una delle tecnologie VPN più scalabili.
L'esempio fornito sarà piuttosto semplice in termini di algoritmi di autenticazione e autorizzazione utilizzati, ma rappresenta una buona opzione per una rapida partenza (cosa che molti stanno attualmente cercando) con la possibilità di un adattamento approfondito alle proprie esigenze durante il processo di implementazione.
Informazioni generali: La tecnologia VPN Load Balancing Cluster non è un failover né una funzione di clustering nel suo significato nativo, questa tecnologia consente di unire modelli ASA diversi (con alcune limitazioni) al fine di bilanciare il carico delle connessioni VPN remote. La sincronizzazione delle sessioni e delle configurazioni tra i nodi di tale cluster non è presente, ma è possibile un bilanciamento automatico del carico delle connessioni VPN e garantire la resilienza delle connessioni VPN finché rimane almeno un nodo attivo nel cluster. Il carico nel cluster viene bilanciato automaticamente in base al carico dei nodi in termini di numero di sessioni VPN.
Per garantire l'affidabilità di specifici nodi del cluster (se necessario), è possibile utilizzare un failover, in modo che la connessione attiva venga gestita dal nodo Primario del failover. Il failover non è una condizione necessaria per garantire l'affidabilità all'interno di un cluster di Load-Balancing; il cluster stesso, in caso di guasto di un nodo, trasferirà la sessione dell'utente a un altro nodo attivo, tuttavia senza mantenere lo stato della connessione, che è invece garantito dal failover. 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 versioni successive.
Poiché ogni ASA all'interno del cluster VPN Load-Balancing è un'unità indipendente dal punto di vista delle configurazioni, eseguiamo tutte le fasi di configurazione in modo individuale su ciascun dispositivo.
Topologia logica dell'esempio fornito:
Distribuzione iniziale:
Distribuiamo istanze ASAv dai modelli necessari (ASAv5/10/30/50).
Assegniamo le interfacce INSIDE/OUTSIDE agli stessi VLAN (Outside nel proprio VLAN, INSIDE nel proprio, ma in comune all'interno del cluster, vedi 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 larghezza di banda di 100 kbit/sec.
- Per installare la licenza, è necessario generare un token nel proprio account Smart-Account: -> Smart Software Licensing
- Nella finestra aperta, cliccare sul pulsante Nuovo Token
- Assicurati che nella finestra aperta ci sia un campo attivo e sia selezionata la casella Consenti funzionalità controllate per l'esportazione… Senza questo campo attivo non sarà possibile utilizzare le funzionalità di crittografia forte e pertanto VPN. Se questo campo non è attivo, si prega di contattare il proprio team di account per richiedere l'attivazione.
- Dopo aver premuto il pulsante Crea token, verrà creato un token che utilizzeremo per ottenere la licenza per l'ASAv, lo copieremo:
- Ripeteremo i passaggi C,D,E per ciascun ASAv distribuito.
- Per facilitare la copia del token, abilitiamo temporaneamente telnet. Configuriamo ogni ASA (l'esempio sottostante illustra le impostazioni su ASA-1). Il telnet dall'esterno non funziona; se è necessario, cambia il livello di sicurezza a 100 su outside e poi ripristinalo.
! 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 l'accesso a Internet per ASA, .
In breve, ASA ha bisogno di:
- accesso HTTPS a Internet;
- sincronizzazione 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 (synced), # master (unsynced), + selected, - candidate, ~ configured ! ! Impostiamo la configurazione del nostro ASAv per Smart-Licensing (in base al 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, è possibile configurare l'accesso a Internet tramite proxy utilizzando il seguente blocco di comandi: !call-home ! http-proxy ip_address port port ! ! Successivamente incolliamo 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 ! ! Attiviamo il server HTTPS per ASDM sulla porta 445 per evitare conflitti con il portale SSL-VPN ! vpn-demo-1(config)# http server enable 445 !- Per far funzionare ASDM, è necessario prima scaricarlo dal sito cisco.com; nel mio caso, questo è il file seguente:
- Per far funzionare il client AnyConnect, è necessario caricare su ciascuna ASA un'immagine per ogni sistema operativo desktop utilizzato (previsto 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 trasferiti su ciascuna singola ASA:
- Configuriamo ASDM e il certificato Self-Signed per SSL-VPN (in produzione è consigliato utilizzare un certificato di fiducia). Il FQDN installato dell'indirizzo virtuale del cluster (vpn-demo.ashes.cc), così come ogni FQDN associato con l'indirizzo esterno di ciascun nodo del cluster, deve risolversi nella zona DNS esterna all'indirizzo IP dell'interfaccia OUTSIDE (o all'indirizzo mappato, se viene utilizzato il port forwarding udp/443 (DTLS) e tcp/443(TLS)). Informazioni dettagliate sui requisiti del certificato sono indicate 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=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 % Il nome di dominio completamente qualificato nel certificato sarà: vpn-demo.ashes.cc Generare certificato self-signed? [yes/no]: yes vpn-demo-1(config)# ! vpn-demo-1(config)# sh cry ca certificates Certificato Stato: Disponibile Numero di serie del certificato: 4d43725e Uso del certificato: Uso generale Tipo di chiave pubblica: RSA (4096 bit) Algoritmo di firma: SHA256 con crittografia RSA Nome dell'emittente: serialNumber=9A439T02F95 hostname=vpn-demo.ashes.cc cn=*.ashes.cc ou=ashes-lab o=ashes c=ru Nome del soggetto: serialNumber=9A439T02F95 hostname=vpn-demo.ashes.cc cn=*.ashes.cc ou=ashes-lab o=ashes c=ru Data di validità: data di inizio: 00:16:17 MSK Mar 19 2020 data di fine: 00:16:17 MSK Mar 17 2030 Memorizzazione: config Trustpoints associati: SELF Certificato CA Stato: Disponibile Numero di serie del certificato: 0509 Uso del certificato: Uso generale Tipo di chiave pubblica: RSA (4096 bit) Algoritmo di firma: SHA1 con crittografia RSA Nome dell'emittente: cn=QuoVadis Root CA 2 o=QuoVadis Limited c=BM Nome del soggetto: cn=QuoVadis Root CA 2 o=QuoVadis Limited c=BM Data di validità: data di inizio: 21:27:00 MSK Nov 24 2006 data di fine: 21:23:33 MSK Nov 24 2031 Memorizzazione: config Trustpoints associati: _SmartCallHome_ServerCA- Per verificare il funzionamento di ASDM, non dimenticate di specificare la porta, ad esempio:
- Procediamo con le impostazioni di base del tunnel:
- Rendere accessibile attraverso il tunnel la rete aziendale, mentre l'internet verrà instradato direttamente (non è il metodo più sicuro in assenza di misure di protezione sull'host connesso, c'è la possibilità di intrusione attraverso un host infetto e di fuoriuscita di dati aziendali, opzione split-tunnel-policy tunnelall invierà tutto il traffico dell'host nel tunnel. Tuttavia, Split-Tunnel permette 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 da 10 a 30 indirizzi (per il nodo #1)). In ogni nodo del cluster VPN il pool deve essere specifico.
- Eseguiremo una base di autenticazione con un utente creato localmente su ASA (anche se questo non è consigliato, poiché è il metodo più semplice), sarebbe meglio fare l'autenticazione tramite LDAP/RADIUS, e sarebbe ancora meglio integrare l'Autenticazione Multi-Fattore (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 ASA per autenticare gli utenti remoti, il che è poco pratico al di fuori di un laboratorio. Mostrerò un esempio di come adattare rapidamente la configurazione per l'autenticazione su RADIUS un server, per esempio abbiamo usato 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 integrare rapidamente la procedura di autenticazione con il servizio directory AD, ma anche distinguere l'appartenenza del computer connesso all'AD, comprendere se si tratta di un dispositivo aziendale o personale e valutare lo stato del dispositivo connesso.
- Configuriamo NAT Trasparente affinché il traffico tra il client e le risorse della rete aziendale non venga NATato:
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 liberare i nostri clienti su Internet attraverso ASA (utilizzando tunnelall opzioni) utilizzando PAT, e anche uscire attraverso lo stesso interfaccia OUTSIDE, da cui si connettono è necessario fare le seguenti impostazioni
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, durante l'uso del cluster, consentire alla rete interna di capire a quale ASA indirizzare il traffico di ritorno agli utenti; per farlo è necessaria la ridistribuzione delle rotte /32 indirizzi assegnati ai clienti.
Attualmente non abbiamo ancora configurato il cluster, ma abbiamo già gateway VPN funzionanti ai quali è possibile connettersi individualmente tramite FQDN o IP.
Vediamo il cliente connesso nella tabella di routing del primo ASA:
Affinché tutto il nostro cluster VPN e l'intera rete aziendale conoscano la rotta verso il nostro cliente, effettueremo la ridistribuzione del prefisso del cliente 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 una rotta verso il cliente dal secondo gateway ASA-2 e gli utenti connessi a diversi gateway VPN all'interno del cluster possono, ad esempio, comunicare direttamente tramite il software aziendale, e anche il traffico di ritorno delle risorse richieste dall'utente arriverà al giusto gateway VPN:
Passiamo alla configurazione del Load-Balancing del cluster.
L'indirizzo 192.168.31.40 verrà utilizzato come Virtual IP (VIP — a cui si connetteranno inizialmente tutti i clienti VPN); da questo indirizzo il Master del cluster farà un REDIRECT verso un nodo del cluster meno impegnato. Non dimenticare di specificare la registrazione DNS diretta e inversa sia per ogni indirizzo esterno / FQDN di ciascun nodo del cluster, sia 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 clienti connessi:
- Rendere l'esperienza di lavoro del cliente più conveniente con il profilo di AnyConnect caricato automaticamente tramite ASDM.
Assegniamo un nome conveniente al profilo e associamo la nostra policy di gruppo con esso:
Dopo la prossima connessione del cliente, questo profilo verrà scaricato e installato automaticamente nel client AnyConnect, quindi basterà semplicemente sceglierlo dall'elenco quando necessario:
Poiché, utilizzando ASDM, abbiamo creato questo profilo solo su un'ASA, non dimenticate di ripetere l'operazione sulle altre ASA del cluster.
Conclusione: In questo modo, abbiamo rapidamente implementato un cluster di più gateway VPN con bilanciamento del carico automatico. Aggiungere nuove nodi al cluster è semplice, ottenendo una semplice scalabilità orizzontale tramite l'implementazione di nuove macchine virtuali ASAv o utilizzando ASA hardware. Il versatile client AnyConnect può ampliare significativamente le possibilità di connessione remota sicura utilizzando la funzione Posture (valutazione dello stato), applicata più efficacemente insieme al sistema di controllo centralizzato e monitoraggio degli accessi Identity Services Engine.
Fonte: habr.com
