Informazioni di riferimento › Guida di riferimento al catalogo delle appliance › Catalogo di sistema › Gateway › INSSLR2 - gateway di input HTTP ridondante con supporto SSL

INSSLR2 - gateway di input HTTP ridondante con supporto SSL

Ultima versione: 1.0.1-2

L'appliance di INSSLR2 è un gateway a 7 layer per le richieste HTTP sicure. Converte le richieste in richieste HTTP non codificate. È possibile utilizzare questa funzionalità per supportare una connessione HTTP protetta sul lato client.

Tuttavia, l'infrastruttura di elaborazione di backend non supporta o non può supportare SSL, incluso:

• mediante un server HTTP leggero che non ha supporto SSL
• mediante server di backend multipli, per prestazioni o per ridondanza, connessi attraverso uno switch di bilanciamento del carico
• mediante server di backend multipli per funzionalità non correlate connesse attraverso uno switch URL
• scaricando la crittografia o la decrittografia SSL su un server separato per migliorare la velocità effettiva

Se configurato, INSSLR2 supporta anche l'autenticazione di certificato di client. In caso di autenticazione mutua di SSL, sia il client che il server scambiano i loro certificati e i loro codici pubblici corrispondenti. Sia il client sia il server, prima di continuare, può contattare l'autorità di certificazione (CA, Certificate Authority) che ha emesso il certificato e confermare che il certificato è autentico.

Nella configurazione predefinita, INSSLR2 funge da gateway a 7 layer per le richieste di connessione HTTP protetta. Fornisce anche un punto di ingresso con firewall per il traffico di rete in un'applicazione. Può essere configurato con un indirizzo IP statico accessibile da Internet.

Quando configurato, è possibile utilizzare due appliance di INSSLR2 in modalità di failover per consentire un servizio ridondante. In questo caso, l'indirizzo IP di INSSLR2 viene eseguito soltanto su uno dei nodi e, in caso di guasto, viene trasferito automaticamente all'altra appliance di INSSLR2. Solo una delle appliance di INSSLR2 è attiva al momento. Durante l'esecuzione in modalità di failover, è possibile configurare INSSLR2 per l'esecuzione in diverse modalità:

• Asimmetrica: una delle appliance è primaria. Quando l'appliance primaria è in linea, assume il controllo dell'indirizzo IP e diventa attiva.

  Se il nodo primario non viene eseguito correttamente o viene interrotto, l'appliance di backup diventa attiva. Quando l'appliance primaria diventa nuovamente disponibile, riassume il controllo dell'indirizzo IP e diventa attiva. L'appliance primaria è quella con l'indirizzo IP più basso (confronto di stringa) nell'interfaccia fover.

• Simmetrica: entrambe le appliance sono primarie. L'appliance che viene avviata per prima assume il controllo dell'indirizzo IP e diventa attiva. L'altra appliance diventa attiva soltanto in caso di guasto o di interruzione della prima appliance.

  Quando la prima appliance diventa nuovamente disponibile, non assume automaticamente il controllo dell'indirizzo IP.

Durante l'esecuzione in modalità ridondante, INSSLR2 offre un'interfaccia sul terminale CTL per:

• forzare INSSLR2 a diventare primario
• forzare INSSLR2 a diventare backup
• controllare lo stato di INSSLR2 primario o di backup.

INSSLR2 monitora costantemente lo stato dell'appliance di backend connessa al suo terminale di HTTP. I controlli dello stato condotti da INSSLR2 possono includere una semplice connessione TCP o una richiesta HTTP più complessa, se specificata sul limite di INSSLR2.

In caso di errore dell'appliance connessa, INSSLR2 segnala un errore al dashboard di griglia oppure, se è in modalità ridondante e configurato per farlo, esegue un failover all'appliance di backup di INSSLR2.

Per supportare le applicazioni che devono essere visualizzate in un indirizzo IP singolo per più di un servizio, configurare INSSLR2 per dirigere il traffico non HTTP direttamente su un terminale di output distinto. Per tali connessioni, l'appliance funge da firewall a 3 layer/router NAT.

Limite

Risorse

note

• Quando si utilizza INSSLR2 in modalità di failover (il valore fover_mode non è impostato su nessuno), la memoria minima è di 192 M.
• La quantità di memoria assegnata a INSSLR2 non influisce sulla sua velocità effettiva. Usare più memoria soltanto per supportare più richieste concorrenti in cui i server di backend possono mantenere le richieste per periodi di tempo eccessivamente lunghi.

Terminali

Proprietà

path/to/keys/ca_list_client.pem. 

path/to/keys/ca_list_client.pem. 

Proprietà del controllo di integrità

Proprietà avanzate utilizzate negli scenari di failover

Volumi

Messaggi di errore

I seguenti messaggi possono apparire nei file di log e nel log di sistema del controller di griglia quando l'appliance non riesce ad avviarsi:

• Impossibile montare il volume di dati
• Impossibile impostare le autorizzazioni sulla condivisione di dati
• impossibile avviare Samba
• impossibile avviare NFS
• impossibile avviare Apache

Prestazioni

Failover di applicazione

INSSLR2 rileva l'errore di INSSLR2 in circa 10 secondi e richiede altri 10 secondi per eseguire il failover sull'altra applicazione. Il tempo totale trascorso dal verificarsi dell'errore dell'applicazione all'intervento dell'altra applicazione è pari a circa 20 secondi.

Tasso di richiesta

INSSLR2 indirizza non meno di 3000 transazioni (coppia richiesta/risposta) al secondo, in base alle dimensioni del documento e alla larghezza di banda di rete disponibile.

Velocità effettiva di dati

INSSLR2 indirizza non meno di 7 MB al secondo, in base alle dimensioni del documento e alla larghezza di banda di rete disponibile

Connessioni concorrenti

Con la sua memoria predefinita, INSSLR2 supporta non meno di 500 richieste in sospeso contemporaneamente. Una richiesta in sospeso è una connessione TCP aperta dal client, su cui sono presenti una o più richieste HTTP non completate in corso.

Il valore massimo di connessioni simultanee dipende dalla memoria libera disponibile. Ciascuna memoria aggiuntiva di 16 MB aumenta il numero di transazioni http concorrenti di 500.

Ad esempio, se utilizza l'esecuzione in modalità ridondante e si vogliono servire 2000 connessioni simultanee, servono 100 M + 3*16 M= 148 M. La memoria minima quando viene si utilizza l'esecuzione in modalità ridondante è 100 M.

Notifiche

Quando viene eseguito in modalità ridondante (il valore fover_mode non è impostato su nessuno), INSSLR2 attiva le notifiche quando diventa attivo o passivo. Ciò avviene all'avvio del nodo attivo o quando si verifica un failover. Ogni nodo invia una notifica che informa se è attivo o passivo.

INSSLR2 invia due notifiche:

• Notifica al dashboard della griglia: appliance di INSSLR2 APP_NAME:COMP_NAME <acquired|gave up=""> resource ip_addr
• Richiesta HTTP mediante il terminale nfy. Spetta al terminale di ricezione eseguire un'azione in base alla notifica.

  L'URL richiesto è:

  http://nfy/ fover_nfy_prefix fover_mode= fover_mode &state= <start|stop> &ip_addr= ip_addr &fover_local_ip= fover_local_ip &fover_remote_ip= fover_remote_ip &fover_netmask= fover_netmask

fover_nfy_prefix può essere utilizzato per modificare la posizione dello script remoto chiamato e/o per aggiungere altri parametri.

Esempi di valori fover_nfy_prefix:

/path/to/script.php?, /path/to/script.php?username=user&password=pass&. 

Note:

• Quando si utilizza un valore fover_nfy_prefix diverso dal predefinito, verificare che termini con ? se fover_nfy_prefix è soltanto il percorso o lo script oppure & se fover_nfy_prefix include parametri aggiuntivi.
• Se un nodo diventa non disponibile, potrebbe non essere in grado di inviare una notifica se diventa passivo. Solo il nodo che è diventato attivo invia la notifica.
• Il timeout per la richiesta http è di 5 secondi per garantire di non rallentare il failover.

Healthcheck

INSSLR2 esegue un cronjob ogni minuto controllando quanto segue:

• Lo spazio libero sul volume di dati è inferiore al 20%
• Il daemon di rsync è in esecuzione (solo se configurato come slave)
• Il processo di replica è in esecuzione (solo se configurato come master). Altrimenti, il processo di replica viene riavviato.

Se si verifica una delle condizioni indicate sopra, viene inviato un messaggio di errore al dashboard della griglia. Se più di un test non riesce, sul dashboard della griglia viene visualizzato un messaggio di sintesi di tutti gli errori.

Ogni errore viene inviato al dashboard della griglia soltanto una volta all'ora. Nessun errore viene segnalato nei primi 5 minuti dopo l'avvio dell'appliance. Ciò previene eventuali falsi allarmi quando l'altro nodo nella replica non si è avviato.

Certificati di server

Per utilizzare SSL, occorre il certificato firmato e il codice privato con cui è stato codificato. Il codice e il certificato devono essere in formato PEM e inclusi in un file singolo specificato dalla proprietà cert_file.

Generazione dei certificati di server

È possibile generare un certificato di server che possa essere firmato da un'autorità di certificazione (CA) attendibile dietro compenso o creare un certificato auto-firmato.

Attenersi alla seguente procedura:

1. Generare un codice privato usando il seguente comando:

   openssl genrsa -out privkey.pem 2048 
   

   Inoltre, è possibile generare un codice protetto di trasmissione mediante il comando seguente. Tuttavia, se si crea un codice protetto di trasmissione, è necessario rimuovere la password prima di utilizzarlo in INSSLR2. INSSLR2 richiede un codice senza password.

   openssl genrsa -des3 -out privkey.pem 2048 
   

2. Creare un certificato mediante una delle opzioni seguenti:
   • Creare una richiesta di certificato e farla firmare da un'autorità di certificazione (CA) attendibile dietro compenso.

     Eseguire il comando seguente:

     openssl req -new -key privkey.pem -out server.csr 
     

     Dopo aver inviato il file .csr all'autorità di certificazione attendibile, viene restituito un certificato firmato (file .crt) che è possibile utilizzare.

   • Creare un certificato auto-firmato per scopi di test. I browser che richiedono il sito emettono degli avvisi sul fatto che il certificato non è firmato da un'autorità di certificazione attendibile.

     Eseguire il comando seguente:

     openssl req -new -x509 -key privkey.pem -out server.crt -days 1095 
     

Uso dei certificati di server

Ora è possibile posizionare il certificato e il codice in un file e utilizzarlo in INSSLR2 eseguendo il comando seguente:

cat privkey.pem  server.crt > server.pem 

Se il codice è protetto da password, è possibile eliminare la password procedendo come segue:

openssl rsa -in key_with_pass.pem -out privkey.pem 

Uso dei certificati di server apache+mod_ssl esistenti

INSSLR2 consente di utilizzare un certificato esistente che si impiega in Apache. Verificare che il codice non sia protetto da password utilizzando i passaggi descritti sopra, quindi posizionare il certificato privato e il codice in un unico file.

Ad esempio:

• cat privkey.pem server.csr > server.pem

Se si usa un certificato a catena, occorre includere il certificato intermedio fornito dal mittente. Posizionare il codice privato, il certificato e il certificato intermedio in un unico file in questo ordine.

Ad esempio:

• cat privkey.pem server.csr sf_issuing.crt > server.pem

Importante: Il codice di firma del server è la prova d'identità del proprio sito Web. È anche vulnerabile, poiché non è codificato da una password per consentire all'appliance di leggerlo senza assistenza.

Quando si installa il codice sul volume di dati, applicare delle misure di protezione del file che contiene il codice. Non utilizzare lo stesso volume di dati per altri scopi e non renderlo visibile a un server Web. Ad esempio, per ospitare dati accessibili dal Web, come pagine HTML e script.

Certificati di client

L'esempio seguente indica come creare la propria autorità di certificazione e utilizzarla per firmare i propri certificati tramite OpenSSL. Questo è stato testato usando OpenSSL 0.9.8b, la stessa versione installata in INSSLR2.

Creazione di un'Autorità di certificazione

Se si dispone già di un'autorità di certificazione utilizzata per creare il certificato del server autofirmato, ignorare questo passaggio e utilizzare tale autorità di certificazione. Quando si creano gli strumenti dell'autorità certificata per l'applicazione in uso, è importante che l'ambiente sia sicuro.

Importante: il codice privato per l'autorità di certificazione è la base di trust per l'applicazione. Non perderlo o fornirlo ad altre parti.

Attenersi alla seguente procedura:

1. Creare una directory di lavoro su un host sicuro e, all'interno di tale directory, creare:
   • mkdir CA
   • mkdir $CA/privato
2. Creare un tasto di RSA protetto da password per CA con una lunghezza di codice di 2048 bit:

   openssl genrsa -des3 -out CA/private/CA_key.pem 2048 
   

3. Dal codice privato creare il certificato di codice pubblico per l'autorità di certificazione:

   openssl req -new -key CA/private/CA_key.pem -x509 -days 365 -out CA/CA_cert.pem 
   

Creazione di certificati di client firmati dall'autorità di certificazione

È possibile creare certificati di client firmati dall'autorità di certificazione.

Attenersi alla seguente procedura:

1. Generare un codice privato RSA:

   openssl genrsa -out clientA_privkey.pem 2048 
   

   Per creare un codice protetto da password, utilizzare lo switch -des3

2. Generare una richiesta di sottoscrizione di certificato (CSR) dal codice privato:

   openssl req -new -key clientA_privkey.pem -out clientA_request.csr 
   

3. Firmare il certificato contenuto nel CSR usando il certificato generato per CA:

   openssl x509 -req -days 365 -in clientA_request.csr -CA CA/CA_cert.pem -CAkey CA/private/CA_key.pem -CAcreateserial -out clientA.cer 
   

Note:

• lo switch -CAcreateserial abilita l'assegnazione dei numeri di serie unici per i certificati pubblicati. Se questo è il primo certificato pubblicato dall'autorità di certificazione, viene creato il file CA/CA_cert.srl per tenere traccia delle assegnazioni dei numeri di serie. Quando si creano i certificati di client successivi, lo switch -CAserial è usato al posto dello switch -CAcreateserial.

  Ad esempio:

  openssl genrsa -out clientB_privkey.pem 2048 
  

  openssl req -new -key clientB_privkey.pem -out clientB_request.csr 
  

  openssl x509 -req -days 365 -in clientB_request.csr -CA CA/CA_cert.pem -CAkey CA/private/CA_key.pem -CAserial CA/CA_cert.srl -out clientB.cer 
  

• Per creare un singolo file formattato PEM che include sia il certificato di client che il codice:

  cat clientA_privkey.pem clientA.cer > clientA.pem 
  

• Per creare il file equivalente in formato pkcs12 che può essere utilizzato dalla maggior parte dei browser:

  openssl pkcs12 -export -in clientA.cer -inkey clientA_privkey.pem -out clientA.p12 
  

Creare i file di elenco di CA usati da INSSLR2

Revoca dei certificati di client firmati da CA

Per revocare un certificato di client pubblicato dall'autorità di certificazione, utilizzare il comando seguente:

openssl ca -config openssl.conf -revoke clientB.cer -crl_reason keyCompromise 

Dove un esempio openssl.conf è mostrato di seguito e il parametro crl_reason è uno fra: unspecified, keyCompromise, CACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold o removeFromCRL. L'abbinamento della ragione è sensibile alle maiuscole e minuscole.

Per ri-generare l'elenco di revoca di certificato (CRL):

openssl ca -config openssl.conf -gencrl -out CA/crl.pem 

In questo esempio, crl.pem è il file che deve essere fornito a INSSLR2 come proprietà di cert_revocation_list.

Un esempio di file di configurazione campione usato per gli esempi di sopra è: 

      ####################################################################

      [ ca ]

      default_ca      = CA_default            # La sezione ca predefinita

      ####################################################################

      [ CA_default ]

      dir             = ./CA                  # Dove viene tenuto tutto

      certs           = $dir/certs            # Dove sono mantenuti i certificati pubblicati

      crl_dir         = $dir/crl              # Dove i crl sono pubblicati

      database        = $dir/index.txt        # file di indice del database.

      #unique_subject = no                    # Impostato su 'no' per consentire la creazione di

                                        # diversi ctificates con lo stesso oggetto.

      new_certs_dir   = $dir/newcerts         # posto predefinito per i nuovi certificati.

      certificate     = $dir/cacert.pem       # Il certificato di CA

      serial          = $dir/serial           # Il numero di serie corrente

      crlnumber       = $dir/crlnumber        # il numero crl corrente

                                        # deve essere commentato per lasciare un V1 CRL

      crl             = $dir/crl.pem          # Il CRL corrente

      private_key     = $dir/private/cakey.pem# Il codice privato

      RANDFILE        = $dir/private/.rand    # file di numero privato casuale

      default_days    = 365                   # tempo per certificare

      default_crl_days= 30                    # tempo prima del CRL successivo

      default_md      = sha1                  # quale md usare.

      preserve        = no                    # mantieni ordine DN trasmesso

      policy          = policy_anything

      [ policy_anything ]

      countryName             = facoltativo

      stateOrProvinceName     = facoltativo

      localityName            = facoltativo

      organizationName        = facoltativo

      organizationalUnitName  = facoltativo

      commonName              = fornito

      emailAddress            = fornito

Creare i file di elenco dell'autorità di certificazione usato da INSSLR2

È possibile creare i file di elenco dell'autorità di certificazione che sono utilizzati da INSSLR2.

Per creare il file identificato dalla proprietà ca_list_client:

1. Accedere al seguente file:

   cat CA/private/CA_key.pem CA/CA_cert.pem > ca_list_client.pem 
   

2. Mettere questo file sul volume del codice o nel volume che è montato su nfs mediante il terminale di fs.

   Se si desidera, il certificato di server di INSSLR2, ad esempio server.pem, può essere creato allo stesso modo dei certificati client e firmato dall'autorità di certificazione creata. Non utilizzare una password per questo certificato.

3. Dopo aver posizionato server.pem e ca_list_client.pem, testare l'autenticazione del certificato client come segue:
   • Per eseguire il test da un browser, importare un certificato di client formattato pkcs12 in Firefox utilizzando:

     Strumenti=>Opzioni=>Visualizza certificati=>Certificati personali=>Importa. Puntare il browser all'indirizzo IP di INSSLR2.

   • Per testare l'handshake SSL da un host remoto utilizzare il comando seguente:

     openssl s_client -host IP-address -port 443 -showcerts -ssl3 -cert clientA.cer -key clientA_privkey.pem -state 
     

Intestazioni di certificato di client

Se un client si connette a INSSLR2 mediante HTTPS e presenta un certificato di client, INSSLR2 aggiunge le seguenti intestazioni alla richiesta restituita al server di backend:

• Dettagli di X-SSL-Subject sul titolare di certificato
• Dettagli di X-SSL-Issuer sull'autorità di certificazione (Autorità di certificazione)
• Numero di serie del certificato di X-SSL-serial (decimale)
• X-SSL-cipher: la crittografia attualmente in uso
• X-SSL-certificate: il certificato di client completo (Multilinea formato PEM)

È responsabilità dell'applicazione utilizzare o non utilizzare queste intestazioni. INSSLR2 trasmette semplicemente le informazioni senza verificarle, ad eccezione della correttezza della firma e della codifica.

Uso tipico

Applicazioni Web

Per consentire l'accesso di http(s) alla sua applicazione, connettere il terminale di HTTP direttamente all'appliance WEB.

Per un'applicazione Web scalabile con il terminale di HTTP connesso a un'appliance HALB.

Gli esempi di configurazione mostrano soltanto le proprietà impostate su valori non predefiniti.

Applicazioni Web con servizi aggiuntivi

Se si hanno più servizi nell'applicazione, oltre a HTTP, è possibile usare INSSLR2 per trasmettere il traffico HTTP al rispettivo terminale e utilizzare il terminale di AUX per altri servizi.

Applicazioni Web con servizi aggiuntivi multipli

Se si dispone di più servizi tcp/udp oltre all'http, è possibile utilizzare INSSLR2 per trasmettere il traffico HTTP al rispettivo terminale HTTP e utilizzare aux per alimentare il traffico restante a PS8. PS8 alimenta quindi il traffico desiderato ai server di backend.

Applicazioni Web ridondanti

Per fornire un'applicazione Web ridondante, copiare l'applicazione e utilizzare INSSLR2 per fornire le funzionalità di failover per l'indirizzo IP esterno.

Nota: se due appliance di INSSLR2 nella stessa applicazione sono configurate per l'esecuzione in modalità ridondante, viene visualizzato un messaggio di avviso quando si configura lo stesso indirizzo IP su due interfacce diverse. Ignorare l'errore.

Applicazione Web di backup

Se si desidera un'applicazione di backup che notifica gli utenti sui tempi di inattività, è possibile utilizzare INSSLR2 per creare un'applicazione di backup che richiede risorse minime.

Appliance in uso:

• utente: gateway di input per le richieste degli utenti
• Web: server Web che visualizza il messaggio di manutenzione

INSSLR2 sull'applicazione primaria

INSSLR2 sull'applicazione di backup

Nota: mediante la scheda Interfacce dell'editor di configurazione dell'applicazione, è possibile configurare gli attributi dell'interfaccia connessa al terminale fover. Ad esempio, le proprietà di fover_local_ip e fover_netmask.

Applicazione Web ridondante in un'applicazione singola

Per eseguire l'applicazione in modalità ridondante senza creare una nuova applicazione, è possibile raddoppiare le appliance ed eseguirle in modalità ridondante. Poiché ciò implica l'utilizzo di almeno due server Web e di due appliance di database nella modalità normale, tutti vengono utilizzati, fornendo la scalabilità. Tuttavia, ciascuno di loro è in grado di servire l'applicazione da solo se l'altra appliance non funziona.

Per aumentare la scalabilità, è possibile aggiungere ulteriori appliance Web e database. In questo esempio, metà delle appliance (in1, sw1, web1, db1) è eseguita in un gruppo di failover e le rimanenti (in2, sw2, web2, db2) sono eseguite in un altro gruppo di failover per consentire all'applicazione di continuare a funzionare dopo un crash del server. Questa applicazione fornisce la ridondanza a un costo molto basso quando tutte le appliance (tranne che per l'appliance di INSSLR2 e di HALB che richiedono risorse molto basse) sono in stato attivo e nessuna risorsa viene spesa per un'appliance di backup che viene eseguita solamente quando la primaria non funziona.

in1

in2

db1

DB2

Applicazione Web ridondante con due applicazioni identiche

È possibile eseguire due applicazioni identiche sulla stessa griglia, ma su server separati o su griglie diverse, se l'indirizzo IP è accessibile da ambedue le griglie. In questo modo l'errore di un server influisce solo su una delle applicazioni.

Nota: se due appliance di INSSLR2 nella stessa applicazione sono configurate per l'esecuzione in modalità ridondante, viene visualizzato un messaggio di avviso quando si configura lo stesso indirizzo IP su due interfacce diverse. Ignorare l'errore.

L'esempio riportato di seguito mostra un'applicazione che utilizza un'appliance di database anch'essa eseguita in modalità ridondante. In caso di guasto di un'applicazione, l'altra può intervenire senza alcuna perdita di dati.

Appliance in uso:

• insslr: gateway di input ridondante per le richieste dell'utente
• admin - gateway di input per l'accesso dei file log
• sw - reindirizza la porta 8080 da admin a ui su db
• repl_in - input per l'applicazione remota per eseguire la connessione all'appliance di db e replicare il database
• web_lb - utilità di bilanciamento di Web per le richieste utente
• web1, web2: server Web con contenuto attivo, ad esempio script CGI
• db - MYSQLR64 configurato sul master e lo slave allo stesso tempo
• content: archiviazione dei file log degli errori del database, contenuto Web e log Web
• logs - archiviazione dei file log degli errori Web
• repl_out - gateway di output per l'appliance di db che si connette all'applicazione remota per replicare il database
• mon - appliance MON

Le richieste del client arrivano sul gateway di insslr. Il gateway inoltra le richieste all'utilità di bilanciamento del carico Web, che indirizza la richiesta a uno dei server Web, web1 o web2.

I server Web accedono al database di db. L'appliance db si connette all'applicazione remota. Per replicare il database, l'applicazione remota è una copia identica in cui l'unica differenza è rappresentata dal server_id del db e dall'installazione di rete.

L'applicazione remota si connette all'appliance db mediante repl_in gateway che è configurato per consentire la connessione soltanto dal gateway repl_out dell'applicazione remota. Le appliance db nelle due applicazioni sono eseguite nella configurazione master-master per garantire che abbiano sempre dati identici.

Esempio di configurazione delle proprietà

Le proprietà che non sono elencate devono essere lasciate ai loro valori predefiniti. L'accesso Web a db è disponibile mediante il gateway di admin sulla porta 8080.

insslr

db

Importante: solo una delle applicazioni è attiva in qualsiasi momento, l'altra è eseguita per il failover ed è usata quando l'applicazione attiva non riesce.

Note:

• INSSLR2 supporta HTTP 1.0 e HTTP 1.1, ma se il client si identifica come MSIE, il supporto di HTTP 1.1 viene disattivato per tale connessione. In questo modo si evitano eventuali problemi in alcune versioni MSIE.
• Se il client non è MSIE, INSSLR2 supporta HTTP 1.1 per il client, incluse le richieste multiple per capacità di sessione TCP. Ciò si verifica anche se il server di backend supporta solo HTTP 1.0.
• INSSLR2 supporta un IP esterno singolo e pertanto è possibile utilizzare un unico certificato SSL.

Questa appliance usa software Open Source e di terze parti

INSSLR2 utilizza i seguenti pacchetti open source di terze parti oltre ai pacchetti open source di terze parti utilizzati dalla classe di base LUX6.