Différences

Ci-dessous, les différences entre deux révisions de la page.

--- checkpoint:vpn-1:vpn-1 [06.03.2007 11:29] – Lien vers l'index CheckPoint youp3
+++ checkpoint:vpn-1:vpn-1 [07.01.2010 12:32] (Version actuelle) – modification externe 127.0.0.1
@@ Ligne 2: / Ligne 2: @@
 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 ====
@@ Ligne 9: / Ligne 12: @@
 ==== 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 disfonctionnement 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 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]]