Anchor | ||||
---|---|---|---|---|
|
Include Page | ||||
---|---|---|---|---|
|
...
Excerpt | |||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||
General InformationThis section provides some basic information about networking questions that are likely to affect Charon-SSP when running in the cloud. Linux Versions and NetworkManagerThere are significant differences regarding the NetworkManager in the different Linux versions (RHEL 7, 8, 9 and derivatives). This section provides an overview of some important differences. There are two basic network configuration systems in the relevant Linux systems:
Linux 7.x:
Linux 8.x:
Linux 9.x:
Additional information about the ifcfg-rh plugin: The ifcfg-rh plugin is used by the NetworkManager to read/write the traditional ifcfg-files in /etc/sysconfig/network-scripts. Each NetworkManager connection corresponds to one ifcfg-file. The plugin does not support all the connection types supported by the original network-scripts package. The plugin currently supports Ethernet, Wi-Fi, InfiniBand, VLAN, Bond, Bridge, and Team connections. This means that, for example, TYPE=Tap is not supported and cannot be handled by the NetworkManager in the ifcfg-file format. In Linux 7.x and Linux 8.x, the network-scripts package can be used to support the ifcfg-file format. In Linux 9.x, this package is no longer available. Thus, unsupported connection types must be manually recreated. Interface MTU ConsiderationsWhen configuring a dedicated network interface for an emulator, ensure that the MTU of the Charon host interface used is not smaller than the MTU used by the legacy guest operating system. Failing to do so will cause network problems. For further information, please refer to the chapter Interface MTU Considerations in this guide.
Host to Guest Communication ConsiderationsThere are several ways a communication between the host operating system and the guest Solaris system can be implemented. For example:
Please note:
External Communication ConsiderationsIn addition to allowing SSH access to the host system for management purposes, it may be necessary to enable Internet communication to the host and guest system or connect host and guest to the customer's network. Please note: Charon hosts based on Charon-SSP AL (Automatic Licensing) marketplace images and using the public license servers always need either direct Internet access or Internet access via NAT from a NAT gateway in the same cloud as the Charon host to access the license server. Recommended way to connect the Charon host and Solaris guest systems to the customer network: To ensure data traffic between the Charon host and guest systems and the customer network is encrypted, it is strongly recommended to use a VPN connection. An example of a simple VPN connection based on an SSH tunnel is described in SSH VPN - Connecting Charon Host and Guest to Customer Network. This connection is based on a bridge between Charon host and guest system and (via an encrypted SSH tunnel) the remote end-point in the customer network. The connection supports L3 and L2 protocols. Cloud providers usually also provides a VPN gateway instance that can be added to the customer cloud network to connect the cloud network to the customer network (for a charge). Recommended way to connect the guest system to the Internet: The Internet connection can be implemented across the VPN to the customer network. In this case, the customer can allow the guest Solaris system to access the Internet exactly following the security policies defined by the customer. Access to the Internet from subnets or guest systems with only private IP addresses: Access to the Internet for subnets with only private IP addresses is possible across a gateway instance providing VPN access to the customer network and allowing (NATted) Internet access via this path. Alternatively, a NAT gateway in the cloud can be used to map the private addresses to public addresses. The NAT gateway can be implemented on a Charon host system, a dedicated customer-operated gateway, or it can often be provided by the cloud provider for a charge. Please note: a Charon-SSP AL host system that use the public license servers always needs either direct Internet access or Internet access via NAT from a NAT gateway in the same cloud as the Charon host to access the public license server. Direct guest system access to the Internet: This not a recommended standard solution for security reasons. However, should it be required, two interfaces with public IP addresses can be assigned to the Charon host. Guest to Guest Layer 2 Communication ConsiderationsShould L2 protocols be required between two guest systems on different host systems, a bridge/tunnel solution similar to the one described in SSH VPN - Connecting Charon Host and Guest to Customer Network must be set up between the two host systems to allow the L2 traffic to pass.
Asymmetric Routing ConsiderationsThis section applies to the case where several interfaces are configured on an instance and they all have IP addresses configured on the Linux level. When you add a secondary NIC to a Linux instance, a new interface (that is, an Ethernet device) is added to the instance and automatically recognized by the OS. Depending on the cloud-provider, DHCP may not be active for the secondary VNIC, and you must configure the interface with a static IP address and add any routes that are relevant for the new interface. Connectivity problems caused by asymmetric routing arise if traffic arrives through one interface and, when the service replies, the reply packets (with the incoming interface's IP address as the source address) go out the other interface. Policy-based routing is required to ensure that packets are sent out via the interface configured with the same IP address that is used as the source IP address in the packet, and to find the correct default gateway (if needed). Please note:
Assumptions:
Problem description:
When adding a second IP interface on the Charon-SSP host, the routing problems described above can occur. They can be solved by creating a second routing table and adding a routing policy as shown in the following example which uses the data provided in the assumptions above:
The example has the following effect:
You can verify the configuration using the commands:
Once you found a configuration solving your problem, you can make the configuration permanent by adding it to a startup script. Please refer to the Linux man pages for ip rule and ip route for more information. Additional information for Charon-SSP marketplace images: the home directory of the sshuser contains a script named active_sec_network.sh. This script is only an example that illustrates how to create a systemd service to activate necessary routes and rules during system boot (instead of using steps 7 and 8 above). Do not use this script without carefully adapting it to your requirements - failing to do so, may make your system unreachable.
Cloud Instance and IP ForwardingIf a Charon cloud instance is to forward IP packages between its interfaces (act as a router), in addition to configuring IP forwarding on Linux (
Without this configuration, the cloud providers block packets that do not contain the IP address of the cloud instance interface in either the source or destination field. |
...
Excerpt | ||
---|---|---|
| ||
This configuration applies to systems with a file-based network configuration where the NetworkManager is either not active, or where network interfaces should be excluded from NetworkManager control (e.g., to be managed by the Charon Manager). The NetworkManager is disabled by default in older Charon-SSP marketplace images that are based on Centos 7. Please note:
To make the second interface usable for the Charon guest system, perform the following steps:
|
Div | ||
---|---|---|
| ||
Basic Interface Configuration with NetworkManager
...
- The interface names used in the following section are for illustrative purposes only. Please familiarize yourself with the interface naming conventions used in your cloud environment.
The sample configuration assumes a Rocky Linux 8.x system and that the interfaces are under the control of the NetworkManager.
- On some cloud platforms, the automatic cloud-specific configuration prevents the operating system configuration to take effect (for example on GCP). Please refer to your cloud-provider's documentation and the Network Management section in the Getting Started Guide of your version for additional information.
In such environments, you have different options to configure network interfaces for use by the guest system. The main options are the following:
...