Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

iptables routing for SNAT and CGNAT modes #1063

Open
jkilpatr opened this issue Dec 3, 2024 · 0 comments
Open

iptables routing for SNAT and CGNAT modes #1063

jkilpatr opened this issue Dec 3, 2024 · 0 comments
Assignees

Comments

@jkilpatr
Copy link
Member

jkilpatr commented Dec 3, 2024

This is a sub issue of #1001 specifically following up on PR #1015

The objective is to overhaul the exit routing options. Presently in master exits can only use a single method of routing Ipv4 user traffic out to the internet. In the new variety of config options that method is called 'NAT' which means to route all exit client traffic directly out of the exit's own IP.

/// This enum describes the different ways we can route ipv4 traffic out of the exit
/// and assign addresses to clients
#[derive(Debug, Serialize, Deserialize, Clone, Eq, PartialEq)]
pub enum ExitIpv4RoutingSettings {
    /// The default and simplest option, all clients are NAT'd out of the exit's own IP
    NAT,
    /// A provided subnet of ipv4 addresses is split between clients as evenly as possible
    /// the exits own ip is used only for management traffic and the exit's own traffic
    /// IP's from this range can be assigned to specific clients. In that case traffic for other
    /// customers will be distributed as evenly as possible over the remaining addresses
    CGNAT {
        subnet: Ipv4Network,
        static_assignments: Vec<ClientIpv4StaticAssignment>,
    },
    /// A provided subnet of ipv4 addresses is assigned one by one to clients as they connect. With an optional
    /// list of static assignments for clients that will always be assigned the same IP. Use this option with caution
    /// if the subnet is too small and too many clients connect there will be no more addresses to assign. Once that happens
    /// the exit will stop accepting new connections until a client disconnects. Be mindful, in cases where a client can not
    /// find another exit to connect to they will be unable to access the internet.
    SNAT {
        subnet: Ipv4Network,
        static_assignments: Vec<ClientIpv4StaticAssignment>,
    },
}

The settings changes and external ip address assignment code are both ready to go. This ticket is for the following pieces of this bigger change.

  1. Get SNAT and CGNAT modes routing properly by setting up iptables rules
  2. Create unit tests for SNAT And CGNAT modes that test user traffic reaching the outside world

For CGNAT

  • The goal is to balance online users between available public ip addresses as evenly as possible. When a user connects and requests client status info they will be assigned an ip through this flow
  • Once an ip for a user exists we have to setup their iptables routes. The iptables rules will look very similar to this function.
  • There are two ways to handle this, one is that we setup an iptables route in this function in here when we notice that a user is online, this would map the users internal ip to the external ip using a nat rule, each client will get it's own rule.
  • the second is that the iptables routes are setup statically once at startup like in NAT mode, dividing the internal ip range equally between external ips, this is not how ip assignment is currently implemented, but it might turn out to be easier to change that.
  • Both options will require some sort of teardown logic where we detect a user needs to be removed from the active list after some constant amount of downtime, this will delete their iptables rules, release their internal ip, and decrement the users count on the external ip they where using.

For SNAT

  • The goal of snat is very simple, every client gets their own external ipv4 address.
  • The iptables rules will look very similar to this function but the issue is the setup/teardown process. When a client comes online we will need to insert an individual iptables rule for that client in here
  • Teardown logic will need to detect users who have not been online in some time and, delete their iptables rules, release their internal ip, and release their external ip
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants