Host access when using macvlan public ip

LXD
1

I am using a profile with macvlan interface defined because I need a public IP for the container. The fact that the container cannot access services on the host turns out to be too problematic.

Is there a way around this problem? Would it be possible to add an extra interface? For example have a normal eth0 and a second macvlan eth1? Or would that still not work because of the way macvlan works.

Another approach for me could be to use default private ip addresses and expose ports on a node to get in with http and ssh. Can I expose ports? How? Are these addresses then fixed after creation. Stop start does not change them? Can fix or set fixed static addresses?

What is the recommended approach if you want access to nodes using SSH for example when using Ansible? Or access to for example a reverse proxy server?

devices:
      eth0:
        nictype: macvlan
        parent: enp9s0
        type: nic
      root:
        path: /
        pool: default
        type: disk
2

I’m not sure I understand your reasoning for needing to use macvlan:

However assuming that is correct, you could add the container to both the macvlan network and the local private lxdbr0, which would then present two NIC interfaces inside the container.

Assuming you want the default gateway to be out via the macvlan interface, you would want to manually configure addressing for the lxdbr0 connected interface inside the container so DHCP doesn’t set a default gateway, or you could disable DHCP service on the lxdbr0 interface on the host.

3

The benefit of macvlan is that, apart from letting your container get a LAN IP address, you can isolate the container from the host (which can be really good). If you really do not want to isolate the container from the host, then you can use a public bridge.

If your only issue is with putting only once the public key from the host into the container, then you can either (from the host) run lxc file push /home/ubuntu/mycontainer.pubkey mycontainer/root/. Or, create a profile and add cloud-init instructions to setup the public-key for you, automatically, upon the creation of the container.

4

Sorry that was a typo. I need a public IP address. Not a public key.

5

Got it.

Well as @simos says you can also use a public bridge rather than macvlan.

Its a bit more convoluted to set up, as it involves moving the LXD host’s current external IP from the external interface to the new bridge. However it would achieve both the ability for the container to have a public IP and the ability to communicate with the host.

6

Or if that is not an option then you could look at using the routed NIC type which would allow a static external IP to be passed to the container, as well as allowing contact with the host, without having to modify the LXD host’s external interface config.

The routed NIC masks the container behind the LXD host’s MAC address (unlike a public bridge or macvlan), which can be useful in certain restricted environments, however it doesn’t support broadcasts.

See https://linuxcontainers.org/lxd/docs/master/instances#nic-routed

2 Likes