vania-janet/multiturn-rag-retrieval-data huggingface dataset:
In turn, the client presents its public key when it connects with the VPN server, and the VPN server uses the CA certificate to verify the public key.

If the client and VPN server certificate are signed by the same CA, then the administrator can use the same certificate instance when they provision the VPN server.

For more information, see [Setting up client-to-server authentication](https://cloud.ibm.com/docs/vpc?topic=vpc-client-to-site-authentication).





 VPN client authentication 

As the VPN server administrator, you must choose at least one authentication method and configure it during the VPN server provisioning. You can choose a client certificate, added security with a user ID and passcode, or both types of client authentication.

Multiple VPN clients can share one client certificate.

If you plan to use the client certificate, the user must edit the client profile provided by the server administrator and include the client certificate (also called the public key) and the private key. Note that modification of the client profile is not necessary if using only using "user ID and passcode" client authentication.

VPN users don't use their password directly to connect to the VPN server. They get the passcode from the IBM Access Manager (IAM) via a browser, and if the MFA is enabled, the MFA enforcement is always done via the browser. The user must configure the MFA properly to make sure the MFA enforcement can be done on the browser. After a user gets the passcode, they input the passcode on the OpenVPN client and initiate the connection.

The VPN server receives the username and passcode from the VPN client and makes an IAM call to verify the passcode and permission with IAM policy.



* The passcode is an one-time password. The user MUST re-generate the passcode for re-connection, even if the re-connection is initiated by the VPN server.
* The SoftLayer MFA is not supported because SoftLayer MFA enforcement is not done via the browser.



If you use user ID/passcode authentication, maintenance activities force users to re-authenticate by fetching and re-entering the code.
[VPN clients](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/vpc/images/vpn-clients.png)

VPN clients

You can also specify to Delete the VPN client, which deletes the client session immediately.







 Disconnecting VPN clients from the CLI 

Before you begin, make sure to [set up your CLI environment](https://cloud.ibm.com/docs/vpc?topic=vpc-infrastructure-cli-plugin-vpc-reference).

To disconnect a VPN client by using the CLI, enter the following command:

The disconnected VPN client is automatically deleted after one hour. To automatically delete a VPN client, use the ibmcloud is vpn-server-client-delete command.

ibmcloud is vpn-server-client-disconnect VPN_SERVER_ID (CLIENT_ID1 CLIENT_ID2 ...) [-f, --force] [-q, --quiet]

Where:



* VPN_SERVER_ID: is the ID of the VPN server.
* CLIENT_ID1: is the ID of the VPN route.
* CLIENT_ID2: is the ID of the VPN route.
* --force, -f: is the force operation without confirmation.
* --quiet, -q: suppresses verbose output.



For example:

ic is vpn-server-client-disconnect r134-46ca4654-fe57-431c-9f5a-1c82773b6e83 86b1f0cc-6e83-45e5-bd78-1bef291be6e7
This will disconnect VPN client 86b1f0cc-16b0-45e5-bd78-1bef291be6e7 and cannot be undone. Continue [y/N] ?> y
When a security
 manager is not set, the default behavior in this implementation
 is to cache for 30 seconds.

 NOTE: setting this to anything other than the default value can have
 serious security implications. Do not set it unless
 you are sure you are not exposed to DNS spoofing attack.

networkaddress.cache.ttl=-1
Show more





 How to modify the JVM's TTL 



* To modify the JVM's TTL for all applications, set the networkaddress.cache.ttl value in the <$JAVA_HOME>/jre/lib/security/java.security file.
* To modify the JVM TTL for a specific application, set the networkaddress.cache.ttl in your application code.

java.security.Security.setProperty("networkaddress.cache.ttl" , "30");









 Java Kafka calls might time out 



 Problem 

Sometimes a Kafka Java client call fails to find Kafka. The cause of failure is that the Kafka client determined the same failing IP address for each of the bootstrap servers. The Kafka client tries each broker’s IP address (which is the same failing IP address) and incorrectly determines that Kafka is down. The Kafka client uses the first IP address that is returned in the list if multiple IP addresses are returned in the DNS query.





 Workaround 

Retry your calls after you wait long enough for the JVM DNS cache for the broker URLs to expire. On subsequent Kafka calls, a working broker IP address is returned from the DNS query.

A Kafka Improvement Proposal (KIP) #302 (available from Kafka 2.1.1) ensures that Kafka clients try all available broker IP addresses and not a subset, so a failure in a single IP address does not cause a failure.

You need to opt into this functionality by using one of the following methods:



* Specify a new allowed value in the Consumer and Producer properties of the configuration parameter client.dns.lookup:

client.dns.lookup: "use_all_dns_ips"
Advanced traffic management 

The following advanced traffic management features are available in IBM Cloud® Application Load Balancer for VPC (ALB).



 Max connections 

Use the max connections configuration to limit the maximum number of concurrent connections for a given front-end virtual port. If you do not configure a value, the system uses a default of 2000 concurrent connections. The maximum concurrent connections for a given front-end virtual port, or system-wide across all front-end virtual ports, is 15000.





 Session persistence 

By default, an ALB forwards received requests to a back-end server based on the configured load-balancing method. You can enable session persistence to ensure that a client remains connected to the same back-end server throughout a session.



 Source IP 

With this option, an ALB creates the affinity between a client and a back-end server based on the source IP of the connection. As an example, if you enable source IP type session persistence for port 80 (HTTP), then any subsequent HTTP connection attempts from the same source IP client are persistent on the same back-end server. This feature is available for all supported protocols (HTTP, HTTPS, and TCP).







 HTTP keep alive 

Application Load Balancer for VPC supports HTTP keep alive when it is enabled on both the client and back-end servers. The load balancer attempts to reuse the server-side HTTP connections to increase connection efficiency and reduce latency.





 TCP keep alive 

Application Load Balancer for VPC supports TCP keep alive. With this setting, the load balancer sends TCP-keep-alive packets to both client and back-end servers every 5 seconds.

This is a socket-level packet with no data that is sent to the peer to notify it that the host is alive. As such, it is seen only at the network layer, and not at the application level. This setting also helps to prevent the disconnection of TCP connections by an intermediate proxy or firewall that might have policies that discard connections after a certain period of inactivity.





 Connection timeouts 

The following timeout values are used by an ALB. Currently, only the client-side and server-side idle timeout values in the following table are custommizable.
Next we build a Docker file that contains the HSM client image. These instructions assume that you have successfully configured your HSM appliance and HSM client. Use these steps to generate an image that is consumable by the IBM Blockchain Platform operator.



* Step one: Modify the HSM client configuration.
* Step two: Build the HSM client image.
* Step three: Push the Docker image to your container registry.
* Step four: Create a Kubernetes secret hsmcrypto.
* Step five: Create the HSM configmap.





 Step one: Modify the HSM client configuration 

Each HSM has its own configuration file that is typically named Chrystoki.conf. This is the main configuration file for the HSM integration and controls many aspects of the HSM client operation. After you install the HSM client, you need to modify the etc/Chrystoki.conf file to point to the hsm folder that contains the HSM shared object library and cryptographic material. The paths specified in Chrystoki.conf represent the location where the IBM Blockchain Platform operator mounts these files on the containers. You need to modify parameters inside the Chrystoki2 and LunaSA Client sections as follows:

Chrystoki2 settings



* LibUnix: Name of the Chrystoki2 library on x86 Linux/UNIX operating systems. The actual name of the library depends on the type of HSM you are using.
* LibUNIX64: Name of the Chrystoki2 library on 64-bit Linux/UNIX operating systems. The actual name of the library depends on the type of HSM you are using.



LunaSA Client settings Typically no changes would be required here unless you have explicitly modified the names of these files.



* ClientPrivKeyFile: Name of the HSM client private key.
* ClientCertFile: Name of the HSM client certificate.
* ServerCAFile: Name of the HSM server certificate.



The following example shows what the file would look like if you were using IBM Cloud HSM. It provides the path to the HSM shared object, certificate and keys.
All DNS requests to 10.114.27.4 are sent to 10.0.80.12.

Line 5 tells the forwarding proxy virtual server to use the virtual DNS for name resolution.





 Configuring the client 

Before continuing to customize the client to use the forwarding proxy, make sure that you cannot reach a public site (for example, http://www.ibm.com) by using the Firefox browser on the client. Because there is no public interface on the client, this request should fail.

The following example configures a Linux client.

You'll need to make a few changes to the client, the first of which is to point the resolver on the client to the virtual DNS. This is done in one of two ways.

You can manually edit the /etc/resolv.conf to point to the virtual address of the DNS. Be aware that client management tools may revert these changes back to the original settings.

Or you can edit the /etc/sysconfig/network-scripts/ifcfg-ethx interface and add the DNS1= statement. After this is set, issue the service network restart command to pick up the changes.

In either case, the DNS IP address must be configured as the virtual DNS address, and the client's browser configured to point requests to the Citrix Netscaler VPX forwarding proxy.

Use the following steps within Firefox to make the necessary changes:



1. Click Preferences > Advanced > Network > Connection Settings.
2. Select Manual Proxy Configuration and enter the following:



* Address: 10.114.27.3
* Port: 80
* Check the Use this proxy server for all protocols checkbox.



3. Click Save and close the browser window.



The IP address 10.114.27.3 is the IP address of the forwarding cache created in Step 1.

At this point, the setup is complete and you can access the internet from the resource isolated on the private network.





 Validating the setup 

Now that the client is configured to use the forwarding proxy, try to access a public site again. The request should now succeed.
* The ability to deploy a CA to a specific Kubernetes cluster zone is only available when SQLite is selected as the CA database.







 Before you begin 

You need to configure an instance of a PostgreSQL database. There are two options available in IBM Cloud:



* [Databases for PostgreSQL](https://cloud.ibm.com/catalog/services/databases-for-postgresql). See the [Getting Started tutorial](https://cloud.ibm.com/docs/databases-for-postgresql?topic=databases-for-postgresql-getting-started) for information on provisioning an instance of the service.
* [Hyper Protect DBaaS for PostgreSQL](https://cloud.ibm.com/catalog/services/hyper-protect-dbaas-for-postgresql). See the tutorial on [Getting started with IBM Cloud Hyper Protect DBaaS for PostgreSQL](https://cloud.ibm.com/docs/hyper-protect-dbaas-for-postgresql?topic=hyper-protect-dbaas-for-postgresql-gettingstarted) for setup instructions.



Use of a third-party PostgreSQL database is also supported. If the third-party database is configured to use TLS, you will need to provide at least one server certificate. If SSL client authentication (mutual TLS) is enabled, you also need to provide a client certificate and a client key in .pem format. More information on how to provide this information is provided in the steps that follow.





 Creating the PostgreSQL connection file 

For all three PostgreSQL database options, you need to provide a file that contains the connection information to the PostgreSQL database when you create the CA. The process to generate the file depends on whether the database resides in IBM Cloud or is from third-party provider.
port=parsed.port,
password=parsed.password,
ssl=True,
ssl_ca_certs='/etc/ssl/certs/ca-certificates.crt',
decode_responses=True)

Redis has a vast array of clients for applications to use. A fairly [comprehensive list is maintained on the Redis site](https://redis.io/clients). Some useful things to keep in mind when choosing a client are features that allow you to easily design your application for the cloud, like configuring [high-availability](https://cloud.ibm.com/docs/databases-for-redis?topic=databases-for-redis-high-availability), security, and self-signed certificate support.





 TLS and self-signed certificate support 

All connections to Databases for Redis are TLS 1.2 enabled, so the driver you use to connect need to be able to support TLS encryption.

If your driver does not support the rediss: protocol or TLS/SSL connections, it is still possible to tunnel connections to the Redis database endpoint by using a TLS/SSL tunnel application such as Stunnel. An example of using Stunnel can be found on the [Connecting with a Command-line Client](https://cloud.ibm.com/docs/databases-for-redis?topic=databases-for-redis-connecting-cli-client) page, where it is used to connect the redis-cli application.

Deployments also come with a self-signed certificate so you can verify the server upon starting a connection. While not required, it is an additional security step that is recommended if your client supports it.



 Using the self-signed certificate 



1. Copy the certificate information from the Endpoints panel or the Base64 field of the connection information.
2. If needed, decode the Base64 string into text.
3. Save the certificate to a file. (You can use the Name that is provided or your own file name).
4. Provide the path to the certificate to the driver or client.
Global load balancing 

Global server load balancing (GSLB) is a method to split traffic across multiple servers using DNS and geographical locations as the means to determine where server traffic should be sent. Generally, a global load balancer sends a client request to a server that is closer to the client, decreasing latency and improving performance.

You might not require a full implementation of a global load balancing solution. GSLB requires multiple instances of a suitable device that can perform this function, and depending on your needs, other solutions might be more attractive to you. If you need entire websites and applications, then GSLB is a good choice. If you only need portions of your content, such as images, videos, or other large files, then a [Content Delivery Network](https://cloud.ibm.com/docs/CDN?topic=CDN-about-content-delivery-networks-cdn-about-content-delivery-networks-cdn-) might be more suitable (and easier to deploy).



 Citrix Netscaler VPX 

The Citrix Netscaler VPX is the only customer configurable device that does true global load balancing. NetScaler is a multi-function appliance that can perform DNS based global load balancing lookups. You can point to the NetScaler as a DNS server, and the device will look over the servers it is configured to load balance for, perform a distance calculation, and return a record with the IP of the server closest to the client request.

For global load balancing, you would have a NetScaler appliance configuration in each data center. Each NetScaler appliance configuration can be a single Netscaler or a pair of Netscalers in an HA pair, depending on your requirements, providing local load balancing services for the servers behind them. The devices are configured to talk to one another so they exchange state information on each server assigned to global load balancer rotation. Any DNS request that comes to these configured NetScalers can return a proper record for a server that is online and responsive. Any server not responsive is removed from the rotation and another is selected.

You must already have load balancing set up, even if it is only one server being balanced.
* When the action is translate, after the packet is decrypted from the tunnel, the source IP of the packet is translated to the private IP of the VPN server, then the packet is sent.



Note which CIDR should be specified when you create the security group and ACL rules.



Table 5. Security group rules for a VPN deliver route on the VPN server

 Inbound/Outbound Rules Protocol Source/Destination Type Source Value 

 inbound ALL CIDR block VPN route destination CIDR Any 
 outbound ALL CIDR block VPN route destination CIDR Any 





Table 6. ACL rules for a VPN deliver route on the VPN server subnet

 Inbound/Outbound Rules Protocol Source IP Source Port Destination IP Destination Port 

 inbound ALL VPN route destination CIDR Any VPN server client IP pool Any 
 outbound ALL VPN server client IP pool Any VPN route destination CIDR Any 



At the same time, you need to configure the security group and ACL on the VPC VSI to unblock traffic from the VPN client:



Table 7. Security group rules for a VPN deliver route on the VPC VSI

 Inbound/Outbound Rules Protocol Source/Destination Type Source Value 

 inbound ALL CIDR block VPN server client IP pool Any 
 outbound ALL CIDR block VPN server client IP pool Any 





Table 8. ACL rules for a VPN deliver route on the VPC VSI subnet

 Inbound/Outbound Rules Protocol Source IP Source Port Destination IP Destination Port 

 inbound ALL VPN server client IP pool Any VPN route destination CIDR Any 
 outbound ALL VPN route destination CIDR Any VPN server client IP pool Any 



For example, if you use 172.16.0.0/20 as the client IP pool when you provision the VPN server, and you want to access the resources of subnet 10.240.128.0/24 from the VPN client, you need to create a VPN route with destination:10.240.128.0/24, and action: deliver. You should also configure security group and ACL rules as follows:



Table 9. Security group rules for a VPN deliver route on the VPN server
Configuring route propagation for VPN servers 

A client IPv4 address pool that is configured for a VPN server is split into multiple subset CIDR ranges, and added to VPC routing tables as the destination. The VPC routing table attribute Accepts routes from controls whether a routing table accepts routes that were added by the VPN server. If VPN server is selected for this attribute, the VPN server propagates routes to this routing table.

Select VPN server in the following cases:



1.  If you want to access a virtual server instance in a subnet from a VPN client, you must select VPN server for the routing table that is associated with this subnet.
2.  For troubleshooting purposes, you can select or deselect VPN server to check routes that were added by the VPN server.



When you create a routing table, make sure to select VPN server if you want VPN server routes propagated to it. For the default routing table, VPN server is selected by default.
Provision a stand-alone VPN server in a subnet, or provision a high availability VPN server in the two subnets. For instructions, see [Creating a VPN server](https://cloud.ibm.com/docs/vpc?topic=vpc-vpn-create-server).
4. [Create VPN routes](https://cloud.ibm.com/docs/vpc?topic=vpc-vpn-client-to-site-routes).
5. [Set up a VPN client environment and connect to the VPN server](https://cloud.ibm.com/docs/vpc?topic=vpc-vpn-client-environment-setup).







 VPN server use cases 

Here are some ways that you can implement the IBM Cloud Client VPN for VPC service:



 Use case 1: Access VPC within a deployed MZR 

The VPN server is deployed in a selected Multi-zone Region (MZR) and VPC. All virtual server instances are accessible from the VPN client in the single VPC.

Zoom

![Network topology: A VPN client can access a virtual server instance within a deployed MZR through the VPN server](https://cloud.ibm.com/docs-content/v1/content/f02b9c9adcbb7328d95a45e105cec371d50f15eb/vpc/images/vpn-server-usecase-vms.png)

Figure 2. Network topology: A VPN client can access a virtual server instance within a deployed MZR through the VPN server





 Use case 2: A VPN client can access the internet through the VPN server 

When the administrator enforces the VPN server in full-tunnel mode, all traffic from customer devices is sent to the VPN server, including internet traffic. The VPN server forwards the internet traffic to the IBM Cloud infrastructure Edge node and finally reaches the internet.

Zoom

!
Click the Organization MSP tile for the organization that your client application interacts with. Click Create connection profile to open a side panel where you can build and download your connection profile.

![Create connection profile panel](https://cloud.ibm.com/docs-content/v1/content/c5288bed34c3820e3a5251d820ee91adcd2591a3/blockchain/images/create-connx-profile.png)

If you plan to use the client application to register and enroll users with the organization CA, you need to include the Certificate Authority in the connection profile definition.

Select the peers to include in the connection profile definition. When a peer is not available to process requests from a client application, service discovery ensures that the request is automatically sent to a different peer. Therefore, to accommodate for peer downtime during a maintenance cycle for example, it is recommended that you select more than one peer for redundancy. In addition to peers created by using the console or APIs, imported peers that have been imported into the console are eligible to be selected as well.

The list of channels that the selected peers have joined is also provided for your information. If a channel is missing from the list, it is likely because the peer joined to it is currently unavailable.

You can then download the connection profile to your local file system and use it with your client application to generate certificates and invoke smart contracts.

The connection profile that is downloaded from the IBM Blockchain Platform console can only be used to connect to your network by using the Node.js (JavaScript and TypeScript) and Java Fabric SDKs.

The generated connection profile only supports Fabric CAs. If you manually built your organization MSP with certificates from an external CA, the connection profile will not include any information in the "certificateAuthorities": section.







 Specifying an endorsement policy 

Every smart contract must have an endorsement policy, that is specified during instantiation. The endorsement policy specifies the set of organizations, the peers, on a channel that can execute the smart contract and independently validate the transaction output. For example, an endorsement policy can specify that a transaction is added to the ledger only if a majority of the members on the channel endorse the transaction.