18301247
Descrição
FlashCards por Usuário eliminado, atualizado more than 1 year ago
Mais
|
Criado por brian gustavo triviño taborda
mais de 7 anos atrás
|
|
|
|
Copiado por brian gustavo triviño taborda
mais de 7 anos atrás
|
|
| Questão | Responda |
| Synchronized Cluster? | ClusterXL uses State Synchronization to keep active connections alive and prevent data loss when a member fails. With State Synchronization, each member "knows" about connections that go through other members |
| ClusterXL virtual IP addresses? | ClusterXL uses virtual IP addresses for the cluster itself and unique physical IP and MAC addresses for the members. |
| Cluster Addresses on Different Subnets? | Only one routable IP address is required in a ClusterXL cluster, for the virtual cluster interface that faces the Internet. All cluster member physical IP addresses can be non-routable. |
| ClusterXL interfaces? | At least three interfaces: one internal interface one external interface one synchronization |
| Synchronization Network? | The synchronization network is used to pass connection synchronization and other state information between cluster members |
| ClusterXL synchronization interface? | It is possible to define more than one synchronization network for backup purposes. The use of more than one synchronization interface in the same synchronization network for redundancy is not supported, as solution you can use Link Aggregation and only one sincronization network. Synchronization interface redundancy is not supported for VRRP clusters. |
| ClusterXL Member IP Address? | All cluster member interfaces facing the same direction must be in the same network there must not be a router between cluster members. |
| Cluster Control Protocol? | It allows cluster members to report their own states and learn about the states of other members by sending keep-alive packets (this only applies to ClusterXL clusters). Also it is used for State Synchronization |
| Cluster Control Protocol port? | UDP port 8116 |
| What services are synchronized through CCP? | Every IP based service (including TCP and UDP) recognized by the Security Gateway is synchronized |
| Must Members in a ClusterXL Load Sharing configuration be synchronized? | Yes |
| Do Members in a ClusterXL High Availability configuration have to be synchronized? | Members in a ClusterXL High Availability configuration do not have to be synchronized, though if they are not, connections will be lost upon failover. |
| How State Synchronization Works (Full Sync Mode)? | Full sync transfers all Security Gateway kernel table information from one cluster member to another. It is handled by the fwd daemon using an encrypted TCP connection |
| How State Synchronization Works (Delta Sync Mode)? | Delta sync transfers changes in the kernel tables between cluster members. Delta sync is handled by the Security Gateway kernel using UDP multicast or broadcast on port 8116. |
| Which services are not synchronized by default in ClusterXL? | The VRRP and IP Clustering control protocols, and the IGMP protocol, are not synchronized by default (but you can choose to turn on synchronization for these protocols. Broadcasts and multicasts are not synchronized, and cannot be synchronized |
| What services should not be synchronized in ClusterXL? | short connections, such as DNS (over UDP) or HTTP. There is no point in synchronizing these connections because every synchronized connection consumes Security Gateway resources, and the connection is likely to have finished by the time a failover occurs. |
| What latency and packet loss should the synchronization network guarantee? | The synchronization network must guarantee no more than 100ms latency and no more than 5% packet loss |
| Can there be a Router that joins the synchronization interfaces of both firewalls? | The synchronization network may only include switches and hubs. No routers are allowed on the synchronization network, because routers drop Cluster Control Protocol packets |
| What are the restrictions regarding members of a ClusterXL? | identically configured platforms and same Check Point software version. |
| What happens during a user-authenticated connection when a failover occurs? | If a cluster member goes down, user-authenticated connections through that member are lost. Other cluster members cannot restore the connection. User authentication state is maintained by a process on the Security Gateway. It cannot be synchronized on members the same way that kernel data is synchronized |
| What happens during a client-authenticated or session-authenticated connection when a failover occurs? | the states of session authentication and client authentication are saved in kernel tables, and can be synchronized |
| What are Delayed Notifications and what services do they apply to? | limited to HTTP-based services. For all TCP services whose Protocol Type is HTTP or None, you can use this option to delay telling the Security Gateway about a connection, so that the connection will only be synchronized if it still exists x seconds after the connection is initiated |
| What is a Sticky Connections? | A connection is considered sticky when all of its packets are handled, in either direction, by a single cluster member |
| What feature of ClusterXL makes a Sticky connection? | there are cases where it is necessary to ensure that a connection that starts on a specific cluster member will continue to be processed by the same cluster member in both directions. To that end, certain connections can be made sticky by enabling the Sticky Decision Function |
| Sticky Decision Function is requerid for | - L2TP traffic - VPN deployments with third-party VPN peers - SecureClient /SecuRemote/ SSL Network Extender encrypted connections - SecureClient visitor mode |
| What happens to members of a ClusterXL when Sticky Decision Funtion is enabled and VPNs are used? | When the Sticky Decision Function is used in conjunction with VPN, cluster members are prevented from opening more than one connection to a specific peer. Opening another connection would cause another SA to be generated, which a third-party peer, in many cases, would not be able to process. Enabling the Sticky Decision Function sets all VPN sessions initiated by the same third-party gateway to be processed by a single cluster member |
| In which file and on which Device is a Tunnel Group created? | On Security Management Server in the file $FWDIR/lib/user.def |
| What is a Tunnel Group used for? | Example: all@{member1,member2} vpn_sticky_gws = {<10.10.10.1;1>, <20.20.20.1;1>}; • ;1 - Tunnel Group Identifier. Indicates that the traffic from these IP addresses should be handled by the same cluster member. Listed peers will always connect through the same cluster member |
| Is a Tunnel Group shared between active cluster members authomatic failover? | Yes |
| What are Non-Sticky Connections? | In a non-sticky connection, a cluster member can receive an out-of-state packet, which Security Gateway normally drops because it poses a security risk. The reply packet returns via a different Security Gateway than the original packet. |
| Could it be a connection involving Static NAT, encrypted connections or Hide NAT being non-sticky? | Static NAT and encrypted connections through a Load Sharing cluster may be non-sticky. Non-stickiness may also occur with Hide NAT, but ClusterXL has a mechanism to make it sticky |
| Is it necessary to activate the synchronization mechanisms to prevent a member from discarding traffic from a non-sticky connection? | If the other members do not know about a non-sticky connection, the packet will be out-of-state, and the connection will be dropped for security reasons. The Synchronization mechanism thereby prevents out-of-state packets in valid, but non-sticky connections, so that these non-sticky connections are allowed. |
| Are non-sticky connections necessary when using asymmetric routing? | Non-sticky connections will also occur if the network Administrator has configured asymmetric routing, where a reply packet returns through a different Security Gateway than the original packet |
| How are TCP sessions managed when using non-sticky connections? | When a client initiates a connection by sending a SYN packet to the server. The SYN passes through cluster member A, but the SYN/ACK reply returns through cluster member B. This is a non-sticky connection, because the reply packet returns through a different Security Gateway than the original packet. The synchronization network notifies cluster member B. If cluster member B is updated before the SYN/ACK packet sent by the server reaches it, the connection is handled normally. If, however, synchronization is delayed, and the SYN/ACK packet is received on cluster member B before the SYN flag has been updated, then the Security Gateway treats the SYN/ACK packet as out-of-state, and drops the connection |
| What is "Flush and Ack" regarding a non-sticky connection? | Flush and Ack process: 1. Cluster member receives first packet (SYN) of a connection. 2. Suspects that it is non-sticky. 3. Hold the SYN packet. 4. Send the pending synchronization updates to all cluster members (including all changes relating to this packet). 5. Wait for all the other cluster members to acknowledge the information in the sync packet. 6. Release held SYN packet. 7. All cluster members are ready for the SYN-ACK. |
| In a ClusterXL failover why would a member be in the "Active Attention" state? | More than one cluster member may encounter a problem that will result in a failover event. In cases where all cluster members encounter such problems, ClusterXL will try to choose a single member to continue operating. The state of the chosen member will be reported as Active Attention. For example, if a cross cable connecting the cluster members malfunctions, both members will detect an interface problem. One of them will change to the Down state, and the other to Active Attention. |
| When Does a Failover Occur? | - Any critical device fails - An interface or cable fails. - The member fails or becomes unstable. - The Security Policy is uninstalled |
| In ClusterXL, what is a critical device? | A critical device is a process running on a cluster member that enables the member to notify other cluster members that it can no longer function as a member. The device reports to the ClusterXL mechanism regarding its current state or it may fail to report, in which case ClusterXL decides that a failover has occurred and another cluster member takes over. |
| What happens if a member in a ClusterXL uninstalls the policies? | When the Security Policy is uninstalled the Security Gateway can no longer function as a firewall. If it cannot function as a firewall, it can no longer function as a cluster member and a failover occur |
| What Happens When a Security Gateway Recovers in a Load Sharing configuration, what are the configuration options? | High Availability configuration options: - Maintain Current Active Security Gateway - Switch to Higher Priority Security Gateway |
| How a Recovered Cluster Member obtains the Security Policy? | Policy recover process: When a failed cluster member recovers, it will first try to take a policy (up to date policy) from one of the other cluster members. If this is not possible, it compares its own local policy to the policy on the Security Management Server. If the policy on the Security Management Server is more up to date than the one on the cluster member, the policy on the Security Management Server will be retrieved. The policy is sent to the IP address defined in the General Properties page of the cluster member object |
| What are the four ClusterXL Modes? | - Load Sharing Multicast Mode - Load Sharing Unicast Mode - New High Availability Mode - High Availability Legacy Mode |
| Load Sharing Multicast Mode? | ClusterXL uses the Multicast mechanism to associate the virtual cluster IP addresses with all cluster members. By binding these IP addresses to a Multicast MAC address, it ensures that all packets sent to the cluster, acting as a Security Gateway, will reach all members in the cluster. Each member then decides whether it should process the packets or not. This decision is the core of the Load Sharing mechanism: it has to assure that at least one member will process each packet (so that traffic is not blocked), and that no two members will handle the same packets (so that traffic is not duplicated). |
| Is it necessary to enable synchronization in a Load Sharing Multicast (ClusterXL) configuration? | The decision function, which is the one that chooses which member of the cluster manages the connection,try to route each connection through a Security Gateway, to ensure that packets that belong to a single connection will be processed by the same member. Unfortunately, this requirement cannot always be enforced, and in some cases, packets of the same connection will be handled by different members. ClusterXL handles these situations using its State Synchronization mechanism, which mirrors connections on all cluster members |
| What is the purpose of ARP packages sent by members of a ClusterXL in Load Sharing Multicast Mode? | The ARP replies sent by a cluster member will indicate that the cluster IP address is reachable via a multicast MAC address |
| When there is a failover in a Load Sharing Multicast (ClusterXL) configuration member, is it necessary for the active member to issue GARP packages? | When a failover occurs, one of the cluster members goes down. However, traffic still reaches all of the active cluster members, and hence there is no need to make changes in the network ARP routing |
| What are the functions of the "Pivot" member in a Load Sharing Unicast (ClusterXL) configuration? | In this mode a single cluster member, referred to as Pivot, is associated with the cluster virtual IP addresses, and is thus the only member to receive packets sent to the cluster The pivot is then responsible for propagating the packets to other cluster members, creating a Load Sharing mechanism Distribution is performed by applying a decision function on each packet, the same way it is done in Load Sharing Multicast mode. The difference is that only one member performs this selection: any non-pivot member that receives a forwarded packet will handle it, without applying the decision function. The pivot member intercepts the ARP request, and responds with the MAC address that corresponds to its own unique IP address |
| How is the "Pivot" member chosen in a Load Sharing Unicast (ClusterXL) configuration? | The pivot member is always the active member with the highest priority. This means that when a former pivot recuperates, it will retain its previous role. |
| What happens when there is a failover of the "Pivot" member in a Load Sharing Unicast (ClusterXL) configuration? | When a failover occurs on the pivot, the second member assumes the role of pivot. New pivot member sends gratuitous ARP |
| What MAC address is associated with the Cluster IP in a New High Availability Mode (ClusterXL) configuration? | The cluster virtual IP addresses are associated with the physical network interfaces of the active member (by matching the virtual IP address with the unique MAC address of the appropriate interface) |
| A member who is in Standby status begins to have problems, can this member participate in the active member election if a Cluster failover occurs in a New High Availability Mode (ClusterXL) configuration? | If the cluster may encounter problems in standby members, these members are not considered for the role of active members, in the event of a failover |
| When a Cluster failover occurs in a New High Availability Mode (ClusterXL) configuration, which layer 2 packets does the new active member send? | The stand-by member (new active member) sends gratuitous ARP requests |
| What are the possible states of a ClusterXL member? | Each state reflects the result of a test on critical devices: - Active - Active attention - Down - Ready - Standby - Initializing - ClusterXL inactive or member is down |
| ClusterXL Active attention state? | Active attention: A problem has been detected, but the cluster member is still forwarding packets because it is the only member in the cluster or there are no other active members in the cluster |
| ClusterXL Down state? | Down: the critical devices is down |
| ClusterXL Ready state? | Ready: State Ready means that the member recognizes itself as a part of the cluster and is literally ready to go into action, but, by design, something prevents the member from taking action. Possible reasons: Not all required software components were loaded and initialized yet and/or not all configuration steps finished successfully yet, It may also be because Software installed on this member has a higher version than the rest of the members in this cluster |
| In which state does a ClusterXL member check for the existence of another active member in high availability mode or the existence of a pivot in load sharing unicast mode? | Before a cluster member becomes Active, it sends a message to the rest of the cluster members, checking whether it can become Active. In High Availability mode it will check if there is already an Active member and in Load Sharing Unicast mode it will check if there is a Pivot member already. The member remains in the Ready state until it receives the response from the rest of the cluster members and decides which state to choose next (Active, Standby, Pivot, or non-Pivot |
| ClusterXL Initializing state? | Initializing:n initial and transient state of the cluster member. The cluster member is booting up, and ClusterXL product is already running, but the Security Gateway is not yet ready |
| What is the next state in ClusterXL? ClusterXL inactive or member is down? | Local member cannot hear anything coming from this cluster member. Forwarding packets?known |
| What happens if a member in a ClusterXL needs to change status? | When a member needs to change its state (for example, when an active member encounters a problem and needs to bring itself down), it first queries the other members for their state. If all other members are down, this member cannot change its state to a non-active one (or else all members will be down, and the cluster will not function). Thus, the reporting member continues to function, despite its problem (and will usually report its state as "active attention"). |
| What is a Problem Notification in ClusterXL? | When a critical device (also known as a Problem Notification, or pnote) fails, the cluster member is considered to have failed. |
| What are the built-in critical devices in a ClusterXL? | built-in critical devices: - The cluster interfaces on the cluster members. - Synchronization: full synchronization completed successfully. - Filter: the Security Policy, and whether it is loaded. - cphad: which follows the ClusterXL process called cphamcset. - fwd: the Security Gateway daemon |
| For the built-in critical device "The cluster interfaces on the cluster members", which are the interfaces that the mechanisms of ClusterXL check? | All that participate in ClusterXL |
| For the built-in critical device "The cluster interfaces on the cluster members", when is a failover generated taking into account the minimum number of functional interfaces? | ClusterXL also sets the required minimum number of functional interfaces to the largest number of functional interfaces seen since the last reboot. If the number of functional interfaces is less than the required number, ClusterXL starts a failover |
| For the built-in critical device "The cluster interfaces on the cluster members", which interfaces are taken into account for the minimum calculation of required functional interfaces? | An interface can be: - Non-secured or Secured. A secured interface is a synchronization interface. - Shared or unique. A shared interface applies only to High Availability Legacy mode. - Multicast or broadcast. The Cluster Control Protocol (CCP) mode used in the cluster |
| For the built-in critical device "The cluster interfaces on the cluster members", what do the DOWN and READ states mean for an interface? | Interfaz DOWN: interface cannot receive or transmit CCP packets, or both Interfaz READ: The interface may also be able to receive but not transmit CCP packets, in which case the status field is read |
| What are the initial states available when registering a critical device defined by the administrator? | initial state Define the status of the <device> that will be reported to ClusterXL upon registration - ok — <device> is alive. - init — <device> is initializing. The member is down. This state prevents the member from become active - problem — <device> has failed. |
| What does it mean to register the status of a Critical Device to the ClusterXL, and what are the possible states? | Report the status of a user defined critical device to ClusterXL. Status to be reported: - ok — <device> is alive - init — <device> is initializing. The member is down. This state prevents the member from become active - problem — <device> has failed. If this status is reported to ClusterXL, the cluster member will become active immediately failover to another cluster member. |
| What happens if a critical device defined by the user and with a timeout of 10 seconds at the time of registration, does not report its status after 10 seconds? | Timeout: - If <device> fails to contact the cluster member within the timeout that was defined when the it was registered, <device> and hence the cluster member, will be considered to have failed - If a critical device is registered with the -t 0 parameter, there will be no timeout, and until the device reports otherwise, the status is considered to be the last reported status |
| What is the "ClusterXL_monitor_ips" script located in $FWDIR/bin used for? | designed to provide a way to check end-to-end connectivity to routers or other network devices and cause failover if the ping fails |
| What is the "ClusterXL_monitor_process" script located in $FWDIR/bin used for? | monitors the existence of given processes and causes failover if the processes die |
| What is the CCP mode for HA New and Load Sharing Unicast Modes? | Multicast mode: Multicast mode is the default Cluster Control Protocol (CCP) mode in High Availability New Mode and Load Sharing Unicast Mode (and also Load Sharing Multicast Mode). |
| What happens when there is a failover in HA mode or Load Sharing unicast mode (not multicast)? | Gratuitous ARP Requests (G-ARPs): After fail-over, the new active member (or pivot member) broadcasts a series of Gratuitous ARP Requests (G-ARPs), The G-ARPS associate the Virtual IP address of the cluster with the physical MAC address of the new active member or the new pivot. A member with a large number of Static NAT entries can transmit too many GARPS and Switches may not integrate these GARP updates quickly enough into their ARP tables so that Switches continue to send traffic to the physical MAC address of the member that failed. Also there are Network components, such as VoIP phones, that ignore GARPs |
| What is the VMAC mode used for in HA mode or Load Sharing unicast mode (not multicast)? | VMAC Mode: By enabling Virtual MAC in ClusterXL High Availability mode, or Load Sharing Unicast mode, all cluster members associate the same Virtual MAC address with all Cluster Virtual Interfaces and the Virtual IP address, the VMAC that is advertised by the cluster members (through G-ARP Requests) keeps the real MAC address of each member and adds a Virtual MAC address on top of it. |
| What MAC address is used for local connections and sync connections when using VMAC Mode? | the real MAC address of each member is still associated with its real IP address |
| On what platform is VMAC Mode supported? | Secure Platform and Gaia |
| What is Forwarding Layer? | The Forwarding Layer is a ClusterXL mechanism that allows a cluster member to pass packets to other members, after they have been locally inspected by the firewall |
| When a member forwards a packet to another member through the forwarding layer once it has been inspected locally, what special item informs the peer member that the packet has already been inspected? | special source MAC address: Packets sent on the Forwarding Layer use a special source MAC address to inform the receiving member that they have already been inspected by another Security Gateway, the receiving member can safely hand over these packets to the local Operating System, without further inspection |
| How and why does a member forward a package to a peer member through the forwarding layer? | If a member decides, upon the completion of the firewall inspection process, that a packet is intended for another cluster member, it can use the Forwarding Layer to hand the packet over to that destination, this is done by sending the packet over a secured network (any subnet designated as a Synchronization network) directly to that member. Encrypted packets are decrypted during the inspection process, and are forwarded as clear-text (unencrypted) data |
| Packets originated by cluster members can pose problems in the following situations: - New High Availability mode. The connection is opened from the stand-by member. All packets from the external host are handled by the active member, instead of the original gateway. - Load Sharing mode. The decision function has selected another member to handle this connection. This can happen since packets directed at a cluster IP are distributed among cluster members as with any other connection. What is the solution to ensure that a packet originated by a security gateway is forwarded to that gateway? | Forwarding Layer |
Quer criar seus próprios Flashcards gratuitos com GoConqr? Saiba mais.