Simplify routing by using separate netns

[fgrsnau]

Early PR to tackle issue #22.

Commits marked with label [HACK] are meant to be rebased/modified later without warning. I will write a comment if I consider the code to be mature enough. (I just want other devs to be able to view/discuss the current progress.)

[fgrsnau]

I will rebase this PR if #24 is merged. (Docker related stuff went to #24 and this PR will only contain netns related changes.)

[sebschrader]

• The HADES_PORTAL_UWSGI_SOCKET directory should be created with tmpfiles.d after rebasing onto #24
• The vrrp command should be renamed to radius-vrrp, to match unauth-vrrp and auth-vrrp. Same goes for keepalived.conf.j2
• Why does the (radius-)vrrp track the eth-auth and eth-unauth interfaces? I think I know why you are doing this, but the these interfaces are veth-pairs, so this doesn't make much sense IMHO.
• Using a bridge to combine the VRRP network interfaces will not work in our oVirt cluster, due to the MAC spoofing counter-measures.

[sebschrader]

I would merge this PR regardless of the bridge issue:

Using a bridge to combine the VRRP network interfaces will not work in our oVirt cluster, due to the MAC spoofing counter-measures.

We can tackle this problem in a different PR/issue. But can you comment on/fix the other things I mentioned?

[sebschrader]

How's the progress on this one?

Could you then fixup/squash the [HACK] commits in the rebase?

[fgrsnau]

I pushed the latest changes. Currently I’m working on the firewall (unfinished, work in progress).

Injecting a virtual ethernet adapter into the auth/unauth namespace is possible for local testing right now (just for the record):

ip netns add test
docker run -t --privileged --name hades hades-dev
docker exec hades ip netns exec unauth ip link del unauth
netns=$(docker inspect -f '{{.State.Pid}}' hades)
ip link add dev veth0 peer name unauth netns $PID
docker exec hades ip set dev unauth netns unauth up
docker exec hades systemctl restart hades-unauth-vrrp
ip link set dev veth0 netns test name eth0
ip netns exec test bash -l
ip link set dev eth0 up
ip link set dev lo up
dhcpcd eth0
su $LOCALUSER -
HOME=/tmp/foo firefox --no-remote

[fgrsnau]

I’m almost done. The only remaining thing I can think of is the auth dns resolver which is unable to connect to the public network. The change is quite simple and we only have to NAT the internal auth P2P IP address in the outer namespace.

The unauth netns does not need connectivity to the public network, so Natting is not necessary yet (will be introduced for #20).

The next step would be to review and test the changes. Testing is a bit complicated. My idea is to use bridges instead of dummy interfaces in the development container. That way we can easily inject one side of a veth-pair and make it a slave of the bridge. The advantage is that the listening interface will not vanish and we don’t have to restart the systemd services.

[fgrsnau]

I’m confused. Which services should be accessible inside the auth network? The default configuration looks like this:

class HADES_AUTH_ALLOWED_TCP_PORTS(Option):
    """Allowed TCP destination ports for unauthenticated users"""
    type = collections.Iterable
    default = (53, 80, 443)

class HADES_AUTH_ALLOWED_UDP_PORTS(Option):
    """Allowed UDP destination ports for unauthenticated users"""
    type = collections.Iterable
    default = (53, 67)

Why do we allow port 80 and 443? As far as I understood the portal should not listen on the auth network interface.

I also don’t understand the configuration of the auth-dhcp server. There are a number of dhcp-ranges set, but as far as I see no request will ever be answered, because dnsmasq does not know how to satisfy the request (no address range available for DHCP request via auth). What was the exact purpose of the auth namespace? As far as I understand Hades is not the default gateway in the auth network (so NAT is not necessary?).

[fgrsnau]

To best of my knowledge the netns transition should be ready. Everything that was working before should still work.

If there is anything not working as intended please let me know. Working on #20 now.

[sebschrader]

Why do we allow port 80 and 443? As far as I understood the portal should not listen on the auth network interface.

You are right, these ports should not be open.

I also don’t understand the configuration of the auth-dhcp server. There are a number of dhcp-ranges set, but as far as I see no request will ever be answered, because dnsmasq does not know how to satisfy the request (no address range available for DHCP request via auth). What was the exact purpose of the auth namespace? As far as I understand Hades is not the default gateway in the auth network (so NAT is not necessary?).

We do not use dynamic DHCP ranges for authenticated users. dnsmasq should only serve static predefined host reservations as defined by the dhcp-host or dhcp-hostsfile options.

The agent will periodically or upon request regenerate the DHCP hostsfile.