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

IPv6 support #844

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

IPv6 support #844

wants to merge 4 commits into from

Conversation

Peetz0r
Copy link
Contributor

@Peetz0r Peetz0r commented Jan 30, 2021

matrix_docker_ipv6_enabled is true by default. I think IPv6 should be everywhere by now.

Nginx now always listens on ipv6.

When the setting is true, the matrix_docker_network gets created with ipv6 enabled. Because we are basically doing NATv6 between the host and the containers there is a service that sets up the ip6tables rule.

I also moved the matrix-certbot into the matrix_docker_network because in my ipv6-only tests it couldn't validate in the default bridge network.

@pushytoxin
Copy link
Contributor

pushytoxin commented Jan 30, 2021

You are running NAT6 in one direction, but I can't see FORWARD DNAT rules for the exposed sockets in the other. How does this even work?
Or does it rely on the userland proxy?

@Peetz0r
Copy link
Contributor Author

Peetz0r commented Jan 30, 2021

You are running NAT6 in one direction, but I can't see FORWARD rules for the exposed sockets in the other. How does this even work?
Or does it rely on the userland proxy?

Yes, it uses the userland proxy for incoming traffic, and it uses NAT6 for outgoing traffic.

As of a few minutes ago I am running this setup on glitch.im, so you see it working when you see @peetz0r:glitch.im talking anywhere.

@pushytoxin
Copy link
Contributor

pushytoxin commented Jan 30, 2021

Last time I tried this, the nginx/coturn logs from IPv6 users and federated servers contained nothing but the userland proxy address, which is the same as the gateway. Is it still like that?

@Peetz0r
Copy link
Contributor Author

Peetz0r commented Jan 30, 2021

Last time I tried this, the nginx/coturn logs from IPv6 users and federated servers contained nothing but the userland proxy address, which is the same as the gateway. Is it still like that?

Correct, they all get reported as fd00::1.

@Peetz0r
Copy link
Contributor Author

Peetz0r commented Jan 30, 2021

Also I did some more testing, and it's still not fully working. When I go inside a container I can reach only v4 servers on the internet somehow. This worked earlier and I have no clue what I am doing...

@Peetz0r Peetz0r marked this pull request as draft January 30, 2021 20:43
@pushytoxin
Copy link
Contributor

Last time I tried this, the nginx/coturn logs from IPv6 users and federated servers contained nothing but the userland proxy address, which is the same as the gateway. Is it still like that?

Correct, they all get reported as fd00::1.

That's kind of a bummer

Type=oneshot
Environment="HOME={{ matrix_systemd_unit_home_path }}"

ExecStart=ip6tables -t nat -A POSTROUTING -s fd00::/80 ! -o docker0 -j MASQUERADE
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
ExecStart=ip6tables -t nat -A POSTROUTING -s fd00::/80 ! -o docker0 -j MASQUERADE
ExecStart={{ matrix_host_command_sh }} -c "ip6tables -t nat -A POSTROUTING -s fd00::/80 ! -o docker0 -j MASQUERADE"

Changing this made it work for me. I don't know if this is the right solution.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That'd be unnecessary shell invocation. It works, but it's not the best. Something involving an absolute path to env is probably the right solution. And I also forgot the second import ip6tables rule in there.

Like I said, this needs more testing before it's ready :p

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is recommended to put absolute paths into ExecStart=, in this case that would be /usr/sbin/ip6tables

@Peetz0r
Copy link
Contributor Author

Peetz0r commented Jan 31, 2021

@aaronraimist your ip6tables rules should now work.

Also I did some more testing, and it's still not fully working. When I go inside a container I can reach only v4 servers on the internet somehow. This worked earlier and I have no clue what I am doing...

This should also be fixed now

@Peetz0r
Copy link
Contributor Author

Peetz0r commented Jan 31, 2021

Last time I tried this, the nginx/coturn logs from IPv6 users and federated servers contained nothing but the userland proxy address, which is the same as the gateway. Is it still like that?

Correct, they all get reported as fd00::1.

That's kind of a bummer

I might spend some time next week on trying out https://github.com/robbertkl/docker-ipv6nat to fix this.

No guarantees, obviously.

@aaronraimist
Copy link
Contributor

Is there anything else that needs to happen here to merge this? It's been working for me. Seems like using https://github.com/robbertkl/docker-ipv6nat could happen in the future.

@spantaleev
Copy link
Owner

matrix_host_command_iptables seems to be unused, so we can remove it.

I was wondering if we need to install iptables explicitly to ensure it's there, but it seems like it's pulled as a dependency for various things on various distros. On Archlinux, even systemd requires iptables to be there. On CentOS 7, iptables is also required by docker-ce one way or another. On Debian (well, Raspbian), iptables is some dependency for containerd.io. I guess we can safely assume that it's available.

@aaronraimist
Copy link
Contributor

Could we move this forward?

@Peetz0r Peetz0r marked this pull request as ready for review April 17, 2021 04:49
@Peetz0r
Copy link
Contributor Author

Peetz0r commented Apr 17, 2021

I guess I'm not gonna do the proper fix for the "everything is fd00::1" issue. But some support might still be better than none. Especially if it's disabled by default.

Having IPv6 disabled by default doesn't sit well with me, but having this PR sitting dormant for months is definitely worse.

Lemme mark as non-a-draft-anymore and get it into a state without conflicts.

Works for all containers

Major downside is that all ipv6 adresses are logged as fd00::1
Required in ipv6-only setups. The default docker network is ipv4-only, so validation would fail.

Our own network has ipv6 (if enabled) so that works fine.
@Peetz0r Peetz0r force-pushed the ipv6 branch 2 times, most recently from bed6253 to 2d04d1e Compare April 17, 2021 05:17
daemon_reload: yes
when: "matrix_ip6tables_systemd_service_result.changed"

- name: Ensure matrix-ip6tables.service is started and autoruns
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should probably inject this into matrix_systemd_services_list and start it as part of --tags=start.

On the other hand, maybe that makes it start too late? We probably wish to have working IPv6 connectivity for the purposes of obtaining SSL certificates, for example..? Is that why this is here?

@CaptainMalu
Copy link

CaptainMalu commented Sep 14, 2023

Any news about this topic?
I'm not good enough with docker and ansible to configure IPv6 support on my own.

I added this part into my vars.yaml to most likely only have to set enable ipv6 for the network creation part. But i'm not sure which dockernetworks need it and if it will work.

docker_daemon_options:
  experimental:  true
  ip6tables:     true
  ipv6:          true
  fixed-cidr-v6: "fc01:1:1:1::/64"
  default-address-pools: [
    { "base": "172.17.0.0/16", "size": 16 },
    { "base": "172.18.0.0/16", "size": 16 },
    { "base": "172.19.0.0/16", "size": 16 },
    { "base": "172.20.0.0/14", "size": 16 },
    { "base": "172.24.0.0/14", "size": 16 },
    { "base": "172.28.0.0/14", "size": 16 },
    { "base": "192.168.0.0/16", "size": 20 },
    { "base": "fc01:1:1:2:1::/104", "size": 112 },
    { "base": "fc01:1:1:2:2::/104", "size": 112 },
    { "base": "fc01:1:1:2:3::/104", "size": 112 },
    { "base": "fc01:1:1:2:4::/104", "size": 112 },
    { "base": "fc01:1:1:2:5::/104", "size": 112 }
    ]

@ly1998117
Copy link

Any news about this topic? I'm not good enough with docker and ansible to configure IPv6 support on my own.

I added this part into my vars.yaml to most likely only have to set enable ipv6 for the network creation part. But i'm not sure which dockernetworks need it and if it will work.

docker_daemon_options:
  experimental:  true
  ip6tables:     true
  ipv6:          true
  fixed-cidr-v6: "fc01:1:1:1::/64"
  default-address-pools: [
    { "base": "172.17.0.0/16", "size": 16 },
    { "base": "172.18.0.0/16", "size": 16 },
    { "base": "172.19.0.0/16", "size": 16 },
    { "base": "172.20.0.0/14", "size": 16 },
    { "base": "172.24.0.0/14", "size": 16 },
    { "base": "172.28.0.0/14", "size": 16 },
    { "base": "192.168.0.0/16", "size": 20 },
    { "base": "fc01:1:1:2:1::/104", "size": 112 },
    { "base": "fc01:1:1:2:2::/104", "size": 112 },
    { "base": "fc01:1:1:2:3::/104", "size": 112 },
    { "base": "fc01:1:1:2:4::/104", "size": 112 },
    { "base": "fc01:1:1:2:5::/104", "size": 112 }
    ]

I used ipv6nat to make the server work on my IPv6 VPS. According to my practice, the federation function works well. For more details, please refer to my repo ipv6 support.

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

Successfully merging this pull request may close these issues.

6 participants