Base de connaissances Zamiz

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== VPN-1 ======
VPN-1 est le nom de la brique de base de l'offre CheckPoint. Son nom ne signifie pas forcément que la licence achetée permette l'utilisation de la fonction VPN.
VPN-1 est donc le module firewall qui va réaliser le filtrage du trafic réseau.
===== Désactivation du chargement de la politique any-any-any-drop =====
Dans certains cas comme la réinitialisation du SIC, CheckPoint charge par défaut une politique qui refuse tous les flux (sauf ceux d'administration bien sûr). Ceci peut être parfois gênant. Voici comment faire pour annihiler ce comportement : il suffit de lancer la commande ci-dessous.
<code>$FWDIR/bin/control_bootsec -r</code>
===== Utilisation de CRL =====
==== Présentation du problème ====
Dans le cadre d'une utilisation de l'authentification des utilisateurs VPN SecuRemote / SecureClient, le module VPN-1 peut être amener à récupérer une liste des certificats révoqués sur un serveur HTTP. En effet, ces certificats sont liés à une autorité de certification (AC) qui peut indiquer dans son certificat racine un serveur de révocation LDAP et deux serveurs HTTP.
Le problème est que VPN-1 sait interroger uniquement la première URL indiquée. Donc si le premier serveur ne répond pas, il n'y a pas de mécanisme automatique pour interroger le second.

==== Solutions possibles ====
Nous partons ici sur l'hypothèse que VPN-1 n'a pas accès au DNS et que le nom du serveur HTTP n°1 est stocké dans son fichier hosts.
  - On dispose d'un seul module : Pas de miracle ! Quand on s'aperçoit du dysfonctionnement du serveur, il faut modifier le fichier hosts pour indiquer l'adresse du second serveur. Un redémarrage du démon VPN-1 (cpstop;cpstart) est nécessaire pour la prise en compte de ce changement.
  - On dispose d'un cluster avec deux modules A et B : Pour éviter d'avoir à redémarrer le démon VPN-1, on renseigne dans le fichier hosts de A l'adresse IP du serveur n°1 et du serveur n°2 sur B (__Attention, le nom lui est celui du serveur n°1 sur les deux modules__). Ainsi si le serveur n°1 ne répond plus, il suffit de provoquer une bascule sur le second module pour interroger le second serveur. Ce qui est tout de même un moindre mal puisqu'une bascule est normalement transparente pour les flux en cours.

===== CPU du module chargé à 100% =====
Si la consommation CPU de votre module passe d'un seul coup à 100%, il est possible que ce comportement survienne avec le dépassement du seuil de sessions simultanées autorisées. Ce seuil est par défaut positionné à 25000, même si le matériel supporte plus. Une première chose à faire est donc de vérifier ce seuil, le comparer avec le nombre de sessions actuel sur le module et de l'augmenter si cela s'avère nécessaire.
\\ 
\\ 
----
[[checkpoint:checkpoint|Retour à l'index CheckPoint]]