You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let’s explore Ubicloud's networking configuration. While the core of our discussion revolves around the dataplane setup, we aim to provide a comprehensive overview of our network's architecture. Here in the following diagram, you see a simplified version of our networking setup for a host. Each yellow box represents an interface.
Features Overview:
Public IPv4 Addressing
Ephemeral Public IPv6 Addressing
Dual-stack Private Addressing (IPv4/6)
1. Network Blueprint
Key Components:
NAT Using nftables:
Incoming Traffic: Traffic directed at a VM's public IPv4 is mapped to its private IPv4 address inside the network namespace.
Outgoing Traffic: Address translation depends on the destination. Traffic headed for the public internet sees its private source address exchanged for a public one, while traffic to private IPs remains unaltered.
DHCP via Dnsmasq:
Each namespace operates an individual Dnsmasq instance, efficiently handling both DHCP requests and router advertisements.
IPsec Integration:
For enhanced private networking, our model includes an IPsec mechanism. Details will follow.
2. Public IPv4 Configuration on Host
Each host is provisioned with a /27 public IPv4 subnet. We can pick any size subnet, /27 is what we go for, for now. That subnet is already routed to our host at the provider level. Activating an IP for a VM involves:
Selecting an IP from the subnet.
Routing the IP to the network namespece's veth interface.
Setting up nftables for address translation.
Engaging Dnsmasq for private IPv4 DHCP services.
Essentially, the public IPv4 acts as a guide for picking the right namespace. From there, nftables and the private IPv4 networking stack take charge.
3. Ephemeral Public IPv6 Configuration
Our ephemeral /64 IPv6 blocks, given by service providers, are further segmented to /79 blocks to assign VMs their public IPv6 addresses. Consider this, the host has a 2a01:4f8:10a:128b::/64 prefix attached, the VM is decided to have Prefix: 2a01:4f8:10a:128b:aaaa::/79
The complete /79 block directs to the VM's veth interface.
Carve a ::1/80 block from the initial /79 and assign it into the veth interface.
Commission Dnsmasq for VM-specific DHCPv6 functionalities with the prefix::2/80 for the VM.
4. Private IPv4 Configuration
The cornerstone of private IPv4 networking is a chosen /26 private subnet. The intricacies of this configuration play out within the VM and its respective namespace. It remains shielded externally due to our reliance on IPsec tunnels.
For instance, subnet is chosen to be 10.0.0.64/26 with a VM IP of 10.0.0.100/32
The full /26 subnet is routed to the tuntap device.
Dnsmasq is configured so that the VM's IP address is dynamically assigned.
IPsec tackles outbound traffic after initial routing to the veth interface.
For each outgoing connection in the same private subnet, we add specific routing rules so that the packets can be sent out.
5. Private IPv6 Configuration
The process mirrors its IPv4 counterpart. Using a hypothetical /64 block, and picking a random /79 block per VM. Such as; fd1c:a0f1:cccc:bbbb:aaaa::/79:
The entire /79 block is routed to its tuntap device.
Dnsmasq is configured for VM-specific /79 address for DHCPv6.
As with IPv4, the IPsec mechanism handles outbound connections.
6. Private Networking via IPsec
The backbone of our private networking? IPsec tunnels. They capture, assess, and manage traffic via IP xfrm policies/states. Here's how:
Outgoing Policy:
Encapsulates traffic between VMs within a private subnet.
Uses public IPv6 addresses of the source and destination VMs.
The encrypted packet reenters the networking stack.
Incoming Policy:
Deciphers incoming packets using the Security Policy Index (SPI) and processes them.
We perform rekeying of the tunnels every 24 hours in a 0 disruption way.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Ubicloud Networking Stack Documentation
Let’s explore Ubicloud's networking configuration. While the core of our discussion revolves around the dataplane setup, we aim to provide a comprehensive overview of our network's architecture. Here in the following diagram, you see a simplified version of our networking setup for a host. Each yellow box represents an interface.
Features Overview:
1. Network Blueprint
Key Components:
NAT Using nftables:
DHCP via Dnsmasq:
IPsec Integration:
2. Public IPv4 Configuration on Host
Each host is provisioned with a /27 public IPv4 subnet. We can pick any size subnet, /27 is what we go for, for now. That subnet is already routed to our host at the provider level. Activating an IP for a VM involves:
Essentially, the public IPv4 acts as a guide for picking the right namespace. From there, nftables and the private IPv4 networking stack take charge.
3. Ephemeral Public IPv6 Configuration
Our ephemeral /64 IPv6 blocks, given by service providers, are further segmented to /79 blocks to assign VMs their public IPv6 addresses. Consider this, the host has a 2a01:4f8:10a:128b::/64 prefix attached, the VM is decided to have Prefix: 2a01:4f8:10a:128b:aaaa::/79
4. Private IPv4 Configuration
The cornerstone of private IPv4 networking is a chosen /26 private subnet. The intricacies of this configuration play out within the VM and its respective namespace. It remains shielded externally due to our reliance on IPsec tunnels.
For instance, subnet is chosen to be 10.0.0.64/26 with a VM IP of 10.0.0.100/32
5. Private IPv6 Configuration
The process mirrors its IPv4 counterpart. Using a hypothetical /64 block, and picking a random /79 block per VM. Such as; fd1c:a0f1:cccc:bbbb:aaaa::/79:
6. Private Networking via IPsec
The backbone of our private networking? IPsec tunnels. They capture, assess, and manage traffic via IP xfrm policies/states. Here's how:
Outgoing Policy:
Incoming Policy:
We perform rekeying of the tunnels every 24 hours in a 0 disruption way.
Beta Was this translation helpful? Give feedback.
All reactions