Informations de référence › Manuel de référence du catalogue d'appliance › Catalogue système › Passerelles › INSSLR : passerelle d'entrée HTTP redondante avec prise en charge SSL

INSSLR : passerelle d'entrée HTTP redondante avec prise en charge SSL

Voir la vidéo

Dernière version : 3.1.2-1

Présentation fonctionnelle

L'appliance INSSLR est une passerelle de couche 7 pour les requêtes HTTP sécurisées. Elle convertit les requêtes en requêtes HTTP non codées. Vous pouvez l'utiliser lorsque le protocole HTTP sécurisé est nécessaire côté client, mais que l'infrastructure de traitement principale ne prend pas en charge SSL ou est dans l'incapacité de le prendre en charge, notamment :

• car elle utilise un serveur HTTP rapide et léger sur lequel SSL n'est pas pris en charge
• car elle utilise plusieurs serveurs principaux, pour des raisons de performance ou de redondance, connectés via un commutateur à équilibrage de charge
• car elle utilise plusieurs serveurs principaux, pour des fonctions dissociées, connectés via un commutateur URL
• car elle décharge le chiffrement/déchiffrement SSL sur un serveur distinct pour accroître le débit

Si elle est configurée pour, INSSLR prend également en charge l'authentification des certificats client. En cas d'authentification mutuelle SSL, le client et le serveur échangent leurs certificats et leurs clés publiques correspondantes. Le client peut contacter l'autorité de certification qui a publié le certificat du serveur et confirmer que le certificat est authentique avant de continuer. Le serveur peut faire de même.

Dans sa configuration par défaut, INSSLR agit comme une passerelle de couche 7 pour les requêtes HTTP sécurisées et fournit également un point d'entrée derrière un pare-feu pour le trafic réseau dans une application CA AppLogic®, que vous pouvez configurer avec une adresse IP statique accessible via Internet.

Si vous effectuez la configuration nécessaire, vous pouvez utiliser deux appliances INSSLR en mode de basculement pour fournir un service redondant. Dans ce cas, l'adresse IP d'INSSLR (configurée via ip_addr) ne s'exécute que sur l'un des noeuds et est automatiquement transférée vers l'autre appliance INSSLR en cas d'échec. Dans tous les cas, une seule appliance INSSLR est active à la fois. En mode de basculement, vous pouvez configurer INSSLR pour qu'elle s'exécute en plusieurs modes :

• Asymétrique - Une des appliances est principale et lorsqu'elle est en ligne, elle reprend l'adresse IP et devient active. L'appliance de sauvegarde ne devient active que si le noeud principal échoue (ou est arrêté). Lorsque l'appliance principale redevient disponible, elle reprend l'adresse IP et devient active. L'appliance principale est celle disposant de l'adresse IP la plus basse (comparaison de chaîne), telle que définie dans la propriété fover_local_ip.
• Symétrique - Les deux appliances sont principales. Dans ce cas, celle qui démarre en premier reprend l'adresse IP et devient active. L'autre appliance ne devient active que si la première échoue (ou est arrêtée). Lorsque la première appliance redevient disponible, elle ne reprend pas automatiquement l'adresse IP.

En cas d'exécution en mode redondant, INSSLR fournit une interface sur son terminal ctl pour :

• forcer INSSLR à devenir l'appliance principale ;
• forcer INSSLR à devenir l'appliance de sauvegarde ;
• vérifier l'état d'INSSLR (principal/sauvegarde).

INSSLR surveille constamment l'état d'intégrité de l'appliance principale connectée à son terminal http. Les contrôles de l'état d'intégrité réalisés par INSSLR peuvent inclure un simple test de connexion TCP ou une requête HTTP plus complexe (spécifiée sur le périmètre d'INSSLR). En cas d'échec de l'appliance connectée, INSSLR renvoie une erreur dans le tableau de bord de grille ou, si elle est exécutée en mode redondant et configurée pour, elle bascule vers l'appliance INSSLR de sauvegarde.

Pour prendre en charge des applications qui doivent s'afficher à une adresse IP unique pour plusieurs services, vous pouvez configurer INSSLR pour diriger le trafic non HTTP de façon transparente vers un terminal de sortie distinct. Pour les connexions de ce type, l'appliance agit comme un routeur NAT/pare-feu de couche 3.

Périmètre

Ressources

La taille de la mémoire par défaut pour la version de 2.7 de CA AppLogic® est passée à 128 Mo. La mémoire minimum reste de 64 Mo.

Notes

• Lors de l'utilisation d'INSSLR en mode de basculement (fover_mode n'est pas none), la mémoire minimum est de 100 Mo.
• La quantité de mémoire attribuée à INSSLR n'affecte pas son débit. Utilisez une plus grande quantité de mémoire uniquement pour prendre en charge plus de requêtes simultanées lorsque les serveurs principaux peuvent conserver les requêtes pour des périodes excessivement longues.

Terminaux

Propriétés

Propriétés de contrôle de l'intégrité

Propriétés avancées (utilisées dans les scénarios de basculement)

Volumes

Messages d'erreur

Les messages suivants peuvent s'afficher dans le fichier journal de l'appliance ou dans le journal système du contrôleur de grille lorsque l'appliance ne parvient pas à démarrer :

• failed to mount data volume
• failed to set permissions on the data share
• Samba failed to start
• NFS failed to start
• Apache failed to start

Performances

Basculement d'applications

INSSLR détecte l'échec de l'autre application INSSLR en 10 secondes environ. Le basculement vers l'autre application prend 10 secondes supplémentaires. La durée totale entre l'échec de l'application et la reprise du trafic sur l'autre application est d'environ 20 secondes.

Taux de requêtes

INSSLR achemine pas moins de 3000 transactions (paires requête/réponse) par seconde, en fonction de la taille de document et de la bande passante réseau disponible.

Débit des données

INSSLR achemine pas moins de 7 Mo/seconde, en fonction de la taille de document et de la bande passante réseau disponible.

Connexions simultanées

Avec sa mémoire par défaut, INSSLR prend en charge pas moins de 500 requêtes en suspens simultanément (une requête en suspens étant une connexion TCP ouverte à partir du client, sur laquelle une ou plusieurs requêtes HTTP sont en cours mais pas terminées). La quantité maximum de connexions simultanées dépend de la mémoire disponible. Chaque supplément de mémoire de 16 Mo augmente le nombre de transactions http simultanées de 500. Par exemple, en cas d'utilisation du mode redondant, si vous voulez pouvoir traiter 2000 connexions simultanément, vous avez besoin de 100 Mo + 3*= 148 Mo. (La mémoire minimum pour l'exécution en mode redondant est de 100 Mo.)

Notifications

Lorsqu'il est exécuté en mode redondant (fover_mode est défini), INSSLR déclenche des notifications lorsqu'il devient actif ou passif et inversement. Cette notification apparaît au démarrage du noeud actif ou lors d'un basculement. (Chaque noeud envoie une notification indiquant qu'il est devenu actif/passif.)

INSSLR envoie deux notifications :

• Une notification au tableau de bord de grille : INSSLR appliance APP_NAME:COMP_NAME <acquired|gave up> resource ip_addr
• Une requête HTTP via le terminal nfy. Il appartient au destinataire de la notification d'agir en conséquence. L'URL demandée est la suivante :

  http://nfy/fover_nfy_prefixfover_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

  Vous pouvez utiliser fover_nfy_prefix pour modifier l'emplacement du script distant invoqué et éventuellement ajouter des paramètres supplémentaires. Exemples de valeurs fover_nfy_prefix : /path/to/script.php?, /path/to/script.php?username=user&password=pass&.

Important :

• Si vous utilisez un autre préfixe fover_nfy_prefix que celui par défaut, veillez à ce qu'il se termine par ? si fover_nfy_prefix est uniquement le chemin d'accès au script et si fover_nfy_prefix inclut éventuellement des paramètres supplémentaires.
• En cas d'indisponibilité d'un noeud, il se peut qu'il ne puisse pas envoyer de notification indiquant qu'il est devenu passif et seul le noeud devenu actif envoie une notification.
• Le délai d'expiration pour la requête HTTP est de 5 secondes de sorte que le basculement n'est pas ralenti.

Outil de contrôle de l'intégrité

INSSLR exécute un cronjob toutes les minutes pour vérifier les aspects suivants :

• Si l'espace disponible sur le volume de données est inférieur à 20 %
• Si le démon rsync est en cours d'exécution (uniquement s'il est configuré en tant qu'esclave)
• Si le processus de réplication est en cours d'exécution (uniquement si configuré en tant que maître). Dans le cas contraire, il redémarre le processus de réplication.

Si l'une des vérifications est exacte, un message d'erreur est envoyé au tableau de bord de grille. Si plusieurs tests échouent, un message reprenant toutes les erreurs sera publié dans le tableau de bord de grille. Chaque erreur ne sera signalée au tableau de bord de grille qu'une fois par heure. Aucune erreur n'est signalée durant les 5 premières minutes suivant le démarrage d'appliance (pour empêcher de fausses alarmes lorsque l'autre noeud dans la réplication n'a pas démarré).

Certificats de serveur

Pour utiliser SSL, vous avez besoin du certificat signé et de la clé privée avec laquelle il a été codé. La clé et le certificat doivent être au format PEM et utiliser un fichier unique spécifié par la propriété cert_file.

Cette section contient les rubriques suivantes :

Génération de certificats de serveur

Utilisation des certificats de serveur

Utilisation des certificats de serveur apache+mod_ssl existants

Génération de certificats de serveur

CA AppLogic® permet de générer des certificats de serveur.

Pour générer des certificats de serveur

1. Générez une clé privée à l'aide de la commande suivante :

   openssl genrsa -out privkey.pem 2048 
   

   Pour générer une clé protégée par mot de passe, utilisez la commande suivante. (Pour utiliser la clé avec INSSLR, vous avez besoin d'une clé sans mot de passe, si vous créez une clé protégée par mot de passe, vous devez d'abord supprimer le mot de passe avant de l'utiliser dans INSSLR.)

   openssl genrsa -des3 -out privkey.pem 2048 
   

2. Vous avez ensuite besoin d'un certificat. Vous avez deux options ici. Créez une requête de certificat et faites-la signer par une autorité de certification approuvée (moyennant frais) ou créez un certificat autosigné à des fins de test. (Dans ce cas, les navigateurs demandant votre site publieront des avertissements selon lesquels le certificat n'est pas signé par une autorité de certification approuvée).

   Pour générer une requête de certificat, exécutez la commande suivante :

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

   Après avoir envoyé le fichier .csr à votre autorité de certification approuvée, vous recevrez en retour un certificat signé (fichier .crt) que vous pouvez utiliser.

3. Pour générer un certificat auto-signé, exécutez la commande suivante :

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

Utilisation des certificats de serveur

Vous pouvez maintenant placer le certificat et la clé dans un fichier et l'utiliser dans INSSLR :

cat privkey.pem  server.crt > server.pem 

Si votre clé est protégée par un mot de passe, vous pouvez supprimer ce dernier en exécutant la commande suivante :

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

Utilisation des certificats de serveur apache+mod_ssl existants

Si vous avez un certificat existant que vous utilisez dans Apache, vous pouvez aussi l'utiliser dans INSSLR. Veillez à ce que la clé ne soit pas protégée par mot de passe (voir ci-dessus) et placez la clé privée et le certificat dans un fichier dans cet ordre.

Exemple :

cat privkey.pem  server.csr > server.pem 

Si vous utilisez un certificat en chaîne, vous devriez également inclure le certificat intermédiaire fourni par son émetteur. Placez la clé privée, le certificat et le certificat intermédiaire dans un fichier en respectant cet ordre.

Exemple :

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

Important : La clé de signature du serveur est la preuve de l'identité de votre site Web. Votre site est vulnérable aussi parce qu'il n'est pas chiffré par mot de passe (de sorte que l'appliance puisse le lire sans votre assistance). Prenez les mesures nécessaires pour protéger le fichier clé, lors de son installation sur le volume de données. N'utilisez pas le même volume de données à d'autres fins et ne le rendez pas visible pour un serveur Web, par exemple, pour héberger des données accessibles sur le Web (pages HTML, scripts, etc.).

Certificats client

L'exemple suivant décrit comment créer votre propre autorité de certification et l'utiliser pour signer vos propres certificats à l'aide d'OpenSSL. Il a été testé à l'aide d'OpenSSL 0.9.8b, la même version que celle installée dans INSSLR.

Cette section contient les rubriques suivantes :

Création d'une autorité de certification

Création de certificats clients signés par l'autorité de certification

Création des fichiers de liste de l'autorité de certification utilisés par INSSLR

En-têtes de certificats client

Création d'une autorité de certification

Si vous disposez déjà de votre propre autorité de certification pour créer des certificats de serveur auto-signés, vous pouvez ignorer cette étape et utiliser cette autorité de certification. Lors de la création des instruments de l'autorité approuvée pour votre application, veillez à ce que l'environnement soit sécurisé.

Création d'une autorité de certification

1. Sur un système hôte sécurisé, créez un répertoire de travail et un répertoire privé dans le répertoire de travail à l'aide des commandes suivantes :

   mkdir CA 
   mkdir CA/private 
   

2. Créez une clé RSA protégée par mot de passe pour l'autorité de certification avec une longueur de clé de 2048 bits :

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

• A l'aide de la clé privée, créez le certificat public-key pour l'autorité de certification :

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

Important : La clé privée pour l'autorité de certification constitue la base de la sécurité pour l'application. Ne la placez donc pas à une endroit inapproprié et ne la partagez pas avec des tiers.

Création de certificats clients signés par l'autorité de certification

CA AppLogic® vous permet de créer des certificats clients signés par l'autorité de certification.

Création de certificats clients signés par l'autorité de certification

1. Générez une clé privée RSA (pour créer une clé protégée par mot de passe, utilisez le commutateur -des3) :

   openssl genrsa -out clientA_privkey.pem 2048 
   

2. Générez une demande de signature de certificat (CSR) à partir de la clé privée :

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

3. Signez le certificat contenu dans CSR à l'aide du certificat généré pour l'autorité de certification :

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

Mise en garde :

• Le commutateur -CAcreateserial permet d'affecter des numéros de série uniques aux certificats publiés. Etant donné qu'il s'agit du premier certificat publié par l'autorité de certification, le fichier CA/CA_cert.srl est créé pour effectuer le suivi des affectations de numéro de série. Lors de la création des certificats clients suivants, le commutateur -CAserial est utilisé à la place du commutateur -CAcreateserial. Par exemple :

  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 
  

• Pour créer un seul fichier au format PEM qui inclut à la fois la clé et le certificat client :

  cat clientA_privkey.pem clientA.cer > clientA.pem 
  

• Pour créer un fichier équivalent au format pkcs12 (pris en charge par la plupart des navigateurs) :

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

Création des fichiers de liste de l'autorité de certification utilisés par INSSLR

Révocation des certificats clients signés par l'autorité de certification

Pour révoquer un certificat client publié l'autorité de certification :

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

Dans lequel un exemple de "openssl.conf" est fourni ci-dessous et le paramètre "crl_reason" est l'un des suivants : unspecified, keyCompromise, CACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold ou removeFromCRL. Reason n'est pas sensible à la casse.

Pour regénérer la liste de révocation des certificats (CRL) :

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

Dans cet exemple, "crl.pem" est le fichier qui doit être fourni à INSSLR en tant que propriété "cert_revocation_list".

Exemple de fichier de configuration utilisé pour les exemples ci-dessus :

      ####################################################################
      [ ca ]
      default_ca      = CA_default            # The default ca section

      ####################################################################
      [ CA_default ]

      dir             = ./CA                  # Where everything is kept
      certs           = $dir/certs            # Where the issued certs are kept
      crl_dir         = $dir/crl              # Where the issued crl are kept
      database        = $dir/index.txt        # database index file.
      #unique_subject = no                    # Set to 'no' to allow creation of
                                        # several ctificates with same subject.
      new_certs_dir   = $dir/newcerts         # default place for new certs.

      certificate     = $dir/cacert.pem       # The CA certificate
      serial          = $dir/serial           # The current serial number
      crlnumber       = $dir/crlnumber        # the current crl number
                                        # must be commented out to leave a V1 CRL
      crl             = $dir/crl.pem          # The current CRL
      private_key     = $dir/private/cakey.pem# The private key
      RANDFILE        = $dir/private/.rand    # private random number file

      default_days    = 365                   # how long to certify for
      default_crl_days= 30                    # how long before next CRL
      default_md      = sha1                  # which md to use.
      preserve        = no                    # keep passed DN ordering

      policy          = policy_anything

      [ policy_anything ]
      countryName             = optional
      stateOrProvinceName     = optional
      localityName            = optional
      organizationName        = optional
      organizationalUnitName  = optional
      commonName              = supplied
      emailAddress            = optional

Création des fichiers de liste de l'autorité de certification utilisés par INSSLR

CA AppLogic® permet de créer des fichiers de liste de l'autorité de certification utilisés par INSSLR.

Création du fichier identifié par la propriété ca_list_client

1. Accédez au fichier suivant :

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

2. Placez ce fichier sur le volume clé ou sur le volume sur lequel nfs est monté via le terminal fs.
3. Si vous le souhaitez, le certificat de serveur INSSLR (par exemple, server.pem) peut également être créé de la même manière que les certificats clients et signés par l'autorité de certification créée. N'utilisez pas de mot de passe pour ce certificat.
4. Une fois que server.pem et ca_list_client.pem sont en place, vous pouvez tester l'authentification du certificat client comme suit :
   • Pour effectuer le test à partir d'un navigateur, importez un certificat client au format pkcs12 dans Firefox à l'aide d'Outils, Options, Afficher les certificats, Vos certificats, Importer. Faites pointer le navigateur sur l'adresse IP d'INSSLR.
   • Pour tester l'établissement de la liaison SSL à partir d'un hôte distant :

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

En-têtes de certificats client

Si un client se connecte à INSSLR à l'aide de HTTPS, et s'il présente un certificat client, INSSLR ajoute les en-têtes suivants à la requête envoyée au serveur principal :

• X-SSL-Subject : informations sur le propriétaire de certificat.
• X-SSL-Issuer details : informations sur l'émetteur du certificat (Autorité de certification).
• X-SSL-serial : numéro de série du certificat (décimale).
• X-SSL-cipher : chiffrement actuellement en cours d'utilisation.
• X-SSL-certificate : certificat complet du client (plusieurs lignes au format PEM).

Il appartient à l'application d'utiliser ces en-têtes ou non. INSSLR transfère simplement ces informations sans effectuer aucune vérification (à l'exception de la signature et de l'exactitude du codage).

Applications Web

Pour fournir un accès http(s) à votre application, connectez le terminal http directement à l'appliance WEB.

Si vous avez besoin d'une application Web évolutive, reliez le terminal http à une appliance HALB.

Configuration des applications Web

Les exemples de configuration ne répertorient que les propriétés définies sur des valeurs autres que celles par défaut et n'incluent pas la configuration réseau (ip_addr, netmask, gateway).

Applications Web avec des services supplémentaires

Si votre application dispose d'autres services que http, vous pouvez utiliser INSSLR pour transférer le trafic http vers son terminal http et utiliser le terminal aux pour les autres services.

Applications Web avec plusieurs services supplémentaires

Si vous avez plusieurs services tcp/udp et le service http, vous pouvez utiliser INSSLR pour transférer le trafic http vers son terminal http et utiliser le terminal aux pour acheminer le reste du trafic vers PS8, qui achemine le trafic désiré vers les serveurs principaux.

Applications Web redondantes

Si vous devez fournir une application Web redondante, vous pouvez copier l'application et utiliser INSSLR pour fournir des fonctionnalités de basculement à l'adresse IP externe.

Application Web de sauvegarde

Si vous souhaitez uniquement une application de sauvegarde pour notifier les indisponibilités aux utilisateurs, vous pouvez utiliser INSSLR pour créer une application de sauvegarde qui requiert des ressources minimales.

Appliances en cours d'utilisation :

• user - Passerelle d'entrée pour les requêtes utilisateur
• web - serveur Web affichant un message de maintenance

INSSLR sur l'application principale :

INSSLR sur l'application de sauvegarde :

Application Web redondante (application unique)

Si vous souhaitez que votre application s'exécute en mode redondant sans créer de nouvelle application, vous pouvez simplement doubler les appliances qu'elle contient et les exécuter en mode redondant. Dans la mesure où cela implique d'utiliser (au moins) deux serveurs Web et deux appliances de base de données, ils sont tout utilisés en mode normal (moyennant leur modularité), mais chacun d'eux peut pour traiter l'application seule au cas d'échec des autres appliances. Si vous avez besoin d'une plus grande modularité, vous pouvez ajouter davantage d'appliances Web et de base de données. Dans cet exemple, la moitié des appliances (in1, sw1, web1, db1) s'exécutent dans un groupe de basculement et le reste (in2, sw2, web2, db2) dans un autre groupe de basculement pour que l'application puisse résister à une panne brutale du serveur. Cette application fournit de la redondance à très faible coût étant donné que toutes les appliances (à l'exception d'une appliance INSSLR et d'une appliance HALB qui requièrent très peu de ressources) sont dans un état actif et qu'aucune dépense n'est effectuée pour une application de sauvegarde qui s'exécute en cas d'échec de la principale.

in1

in2

db1

db2

Application Web redondante (deux applications identiques)

Vous pouvez exécuter deux applications identiques sur la même grille (mais sur des serveurs distincts pour que seule application soit affectée en cas d'échec de l'un des serveurs), ou sur des grilles différentes, pour autant que l'adresse IP que vous utilisez soit accessible par les deux grilles. L'exemple ci-dessous présente une application qui utilise une appliance de base de données qui s'exécute également en mode redondant pour qu'en cas d'échec d'une application, l'autre application prenne le relais sans perdre de données.

Appliances en cours d'utilisation :

• in1 - Passerelle d'entrée redondante pour les requêtes utilisateur
• admin - Passerelle d'entrée pour l'accès aux fichiers journaux
• sw - Redirige le port 8080 de l'administrateur vers ui sur db
• repl_in - Entrée pour que l'application distante se connecte à l'appliance de base de données afin de répliquer la base de données
• web_lb - Equilibreur de charge Web pour les requêtes utilisateur
• web1, web2 - Serveurs Web hébergeant du contenu actif (par exemple, scripts CGI)
• db - MYSQLR64 configuré pour être simultanément maître et esclave
• content - Stockage des fichiers journaux d'erreurs de base de données, du contenu Web et des journaux Web
• logs - Stockage des fichiers journaux d'erreurs de base de données
• repl_out - Passerelle de sortie pour que l'appliance de base de données se connecte à l'application distante afin de répliquer la base de données
• mon - Appliance MON

Les requêtes client arrivent sur la passerelle in1. Cette dernière envoie les requêtes à l'équilibreur de charge web_lb, qui les transmet à un des serveurs Web web1 et web2. Les serveurs Web accèdent à la base de données db. L'appliance de base de données se connecte à l'application distante (qui est une copie identique, la seule différence étant l'ID de serveur de la base de données et la configuration réseau) pour répliquer la base de données. L'application distante se connecte à l'appliance de base de données via la passerelle repl_in qui est configurée pour n'autoriser la connexion que de la passerelle repl_out de l'application distante. Les appliances de base de données des deux applications s'exécutent dans une configuration maître-maître afin que leurs données soient toujours identiques.

Exemple de configuration de propriétés (les propriétés qui ne figurent pas dans les tableaux ci-dessous doivent être définies sur leurs valeurs par défaut) :

L'accès Web à la base de données est disponible à l'aide de la passerelle admin sur le port 8080.

in1

db

Important : Seule une des applications doit être active. L'autre s'exécute simplement pour le basculement et est utilisée en cas d'échec de l'application active.

Notes

INSSLR prend en charge HTTP 1.0 et HTTP 1.1, mais si le client s'identifie lui-même comme MSIE, la prise en charge de HTTP 1.1 est désactivée pour cette connexion (afin d'éviter les bogues dans certaines versions de MSIE).

Si le client n'est pas MSIE, INSSLR prend en charge HTTP 1.1 pour le client (y compris la prise en charge de requêtes multiples par session TCP), même si le serveur principal ne prend en charge que HTTP 1.0.

INSSLR ne prend en charge qu'une seule adresse IP externe. Par conséquent, vous ne pouvez utiliser qu'un seul certificat SSL.

Logiciels tiers et libres utilisés au sein de l'appliance

INSSLR utilise les packages tiers libres suivants en plus des packages tiers libres utilisés par sa classe de base LUX6.