I've developed a script that uses the Linode API to create a Linode server, add a private ip address, configure it with ansible and add it to a NodeBalancer. The last part I'm about to automate is allowing it access to the database server (another Linode server with private ip address) via firewall rules modification.

Before I implement this, I was wondering if there were any properties of the Linode private network I could use to my advantage. For example, I know they're not, but IF private ip's were private to a single account, I wouldn't even need to worry about this. Is there anything along these lines I could use to make my job easier?

Or is there another way besides a firewall to limit access to between only my Linodes? For example, is it possible to create a VLAN for my Linodes (and would this help limit access)? Or does anyone know how stable a ssh tunnel is if I were to open one up with autossh everytime on boot-up that tunneled to the database server? I think a ssh tunnel would be a big performance hit though.

I'm asking mainly because while it's possible to dynamically modify iptables rules, it is not pretty. I'm not opposed to complex configuration as long as it is clean and reproducible, because dynamic iptables even when using ipset is just... ugh.

Thanks for any suggestions, ideas and insights!

You could use IPv6 instead of IPv4 for DB access. Allow your entire IPv6 pool or a part of it access to the DB server, then assign an address in the pool or part of it to the new server.

What is it about ipv6 that would make this limited to my linodes? Why wouldn't I need a firewall like I would with ipv4? Thanks!

The fact that you have a fixed IPv6 block assigned to just your Linodes (assuming you use a pool, and not the default SLAAC address, which is within Linode's block).

That is, while you would still need to have a single firewall entry for the entire block, the entry can be a static component of your ansible configuration (or at least a task parameter if working with different groups of Linodes under different blocks), with no need to vary it dynamically based on a particular private address assigned to a new Linode.

-- David

Thanks guys! Exactly the info I was looking for.

To automate the ipv6 address assignment from my pool, I suppose I could just use the public ipv4 assigned address as the ipv6 device ip (assuming I use a /64 or /56 pool)?

Sure, whatever works best for you - assignment within a private pool is however you like.

-- David

So I found out from Linode support (have to say stellar support. They respond within minutes!) that the /64 and /56 pools are routed blocks assigned to a specific linode. All traffic to any IP in the pool goes only to the linode the pool was assigned to (call this linode A). If I assign addresses from the pool to my other linodes (say linodes B and C), I would have to somehow determine and route all the traffic received at linode A to linodes B and C.

The /116 pool, however, doesn't work like this. Addresses assigned to your linodes from a /116 pool just work regardless of which linode the pool was assigned to, without any special routing configurations. In light of this, I would want to use a /116 pool, but what linode specific information can I get from the Linode API that is only 12 bits to automatically provision the device ip of a /116 address? I could use a hash of some sort, but then I'd have to detect collisions.

I doubt I will use a /64 pool with the routing requirements, but how would one go about this? Using ip6tables and forwarding to the link-local address? Then I think I wouldn't be any better off if you read my original post.

Thanks everyone for your help.

Hmm, drat, for some reason I thought only the /56 got routed that way (the IPv6 library document seems to use a /64 in its example in the address pool section). Though I have to admit I've only got a /116 and /56 (routed to an address in the /116) since I got them before /64 was added as the default option.

Fitting in 12-bits stateless is definitely a bit of a challenge, and I agree about collisions when trying to generate the 12-bits from another source. But assuming you're keeping some sort of state at all (even if just tracking what accounts/Linodes you have created at a high level) you could probably just use your own numbering, increasing it by each Linode created. Either a single global counter (much like Linode's own linode id), or perhaps hold a reference to the last Linode, retrieving it's number as a starting point when creating new ones. Even if not tracking state now, adding support for doing so minimally for counting Linodes you create is likely less work and/or more reliable than trying to develop a bulletproof way to assign addresses statelessly.

Though I guess in such a case it's also reasonable to start comparing the effort to do that to your original question of reliably modifying iptables for the IPv4 private addresses...

-- David