The default behaviour is significantly changed since the previous
version, so upgrading might require changing the configuration file,
especially if not using it in a fairly standard 464XLAT environment
(e.g., as an SIIT-DC Edge Relay). According to the Semantic Versioning
standard, such changes require the major version to be bumped.
This works around a bug in Net::DNS (or arguably in IO::Socket::IP)
which causes it to refuse to send queries to IPv4 nameservers (even
localhost), when running on IPv6-only hosts. Since IPv6-only hosts are
the primary use case for clatd, and most modern Linux distributions are
shipping with systemd-resolved listening on 127.0.0.53 by default, this
prevents PLAT prefix discovery from working correctly out of the box.
Forcing Net::DNS to use an IPv6 socket, by simply substituting all IPv4
addresses in the name server as IPv4-mapped IPv6 addreses, successfully
works around this problem.
This bug has been present in Net::DNS since version 1.03 (more
specifically since SVN r1406, dated 2015-10-05). This version started
defaulting to using IO::Socket::IP for all sockets, so it is no longer
necessary to require it explicitly in clatd.
For more info:
https://rt.cpan.org/Public/Bug/Display.html?id=158714 (Net::DNS)
https://rt.cpan.org/Public/Bug/Display.html?id=132760 (IO::Socket::IP)
UFW is the standard local firewall framework in Debian-based
distributions. If it is installed and active, add rules that permit
routed traffic between the CLAT and the PLAT prefix. This traffic is
dropped by the default UFW ruleset, leading to issues such as #42.
Adds support for clat-v6-addr=shared and make this the default
behaviour. This makes the CLAT function share the address the host OS
uses for direct IPv6 connection towards the PLAT prefix, thus removing
the previous requirement for a secondary IPv6 address dedicated to the
CLAT function.
When using a shared address in this manner, enable connection tracking
marking by default (so that direct IPv6 connections from the host OS to
IPv4 destinations behind the PLAT keeps working) and disable Proxy-ND
(as there is no need for it, as the host OS kernel will handle NDP
interactions all on its own).
To use the previous default behaviour, use clat-v6-addr=derived.
Closes#25Closes#46
This moves the route for IPv6 traffic from the PLAT to the CLAT into a
separate routing table, and uses the Linux kernel's routing policy
framework to redirect traffic into this routing table.
This makes it possible to set `clat-v6-addr` to an address also used by
the main host OS, removing the requirement for having a dedicated
secondary address assigned to the CLAT.
Additionally, support using nftables to set a connection tracking mark
on outbound connections from the CLAT, and ensuring only return traffic
matching that mark is returned back to the CLAT. This makes it possible
for the CLAT to share an IPv6 address with the main host OS without
breaking connectivity to DNS64-synthesised IPv6 addresses.
The trade-off of using a connection tracking mark is that the CLAT can
not receive unsolicited traffic from the IPv4 Internet via the PLAT.
However in the common case, where the PLAT is Stateful NAT64, that is
the case no matter what.
Closes#25.
The ip6tables frameworks has been deprecated for quite a while now, as
it has been replaced by nftables. On modern distributions, rules added
with ip6tables are just converted to nftables rules and are added to an
ip6tables compatibility table there. This changed the name of the kernel
modules, breaking ip6tables auto-detection (cf. issues #42 and #44).
Unfortunately, due to the way nftables works, these rules can no longer
be relied upon to ensure the CLAT traffic is allowed. This is due to the
fact that in nftables, *all* chains that hook into a packet's path must
return an «accept» verdict in order for the packet to be ultimately
accepted, while it is enough for a single chain to return a «drop»
verdict in order for the packet to be dropped.
That means that the rules that accepts CLAT traffic might be overridden
by a «default drop» rule added to another chain in another table, e.g.,
by firewalld or similar local firewall frameworks. See #23 for an
example of this.
On the other hand, if there is no drop rule anywhere, the rules added by
clatd are superfluous to begin with, as the default kernel behaviour is
to accept the packages.
Therefore just remove support for ip6tables entirely. Users of
firewalld, ufw, or similar local firewall frameworks will need to make
sure that rules are added in those frameworks that permit the CLAT
traffic, e.g., by using `script-up`, like so for ufw:
```
script-up=ufw route allow in on $clat_dev out on $plat_dev
```
Native support for adding rules to the most common local firewall
frameworks might be added in the future.
Closes#44 (no longer applicable).
The following commits changed only clatd.systemd, but it makes sense to
applt them to clatd@.systemd as well.
eb27dd5 clatd.systemd: pull inn network-online.target
00fa0f3 SystemD service: ensure service starts after DNS queries (e.g. ipv4only.arpa) can be resolved.
According to systemd.special(7):
> Units that strictly require a configured network connection should
> pull in network-online.target (via a Wants= type dependency) and
> order themselves after it.
The Wants= dependency was missing, add it.
This allows clatd to use [nat46](https://github.com/ayourtch/nat46)
kernel translator instead of TAYGA. It uses automatic detection - if
`nat46` module is loaded, it will get used, otherwise the application
falls back to using TAYGA.
Signed-off-by: Ondřej Caletka <ondrej@caletka.cz>
This fixed the following dependency loop that could occur when the
system was booting up:
1. NetworkManager configures a network interface and fires off the clatd
dispatcher script.
2. The dispatcher scripts tries to restart `clatd.service`.
3. However, `clatd.service` cannot be (re)started at this point because
its dependency `network-online.target` has not yet been reached.
4. Therefore, the `systemctl restart clatd.service` command in the
dispatcher script blocks, waiting for `network-online.target` to be
reached.
5. But that won't happen until the dispatcher scripts finishes...
Adding `--no-block` allows the dispatcher script to finish immediately
without waiting for the restart to complete (instead, systemd will do it
in the background once `network-online.target` has been reached).
Furthermore, since `clatd.service` may end up being restarted several
times during a boot process (especially on a system with many network
interfaces handled by NetworkManager), it is also at risk of
inadvertently triggering the restart rate-limiting feature in systemd,
so disable that while we're at it.
Closes#22. Thanks to @patrakov for the report!
Perl module IO::Socket::INET6 is obsolete and recomended one is
IO::Socket::IP, which has compatibility to old one.
btw: Net::DNS was rewrited to use IO::Socket::IP.
The previous code would fail to detect PLAT prefix if ipv4only.arpa resolved to
an address such as 2001:db8:c000:aa::c000:aa. It would get confused as to
whether the prefix was 2001:db8::/32 (incorrect) or 2001:db8:c000:aa::/96
(correct).
Bug reported by Kasper Dupont - thanks!
Now that TAYGA is avaiable in EPEL, it is better to point people at that
instead of building TAYGA from source. In commit 18dca08 the build from source
functionality was removed. Update documentation accordingly.
Don't assume that utilities such as systemctl or initctl is found in a certain
specific path. Instead look for them in $PATH. This applies to both the
Makefile and the NetworkManager dispatcher script.
Resolves#11.
The three I-Ds that describe SIIT-DC and SIIT-EAM have been published as
RFCs, so update the references accordingly. Also update once occurrence
of old terminology ("Host Agent") with the new and final one ("Edge
Relay").
Change "2014-2015" with "2014-2016". Also, I had forgotten to update the
licence comment in the clatd script itself in b5725c0, so fix that too.
Thanks to @ingvarha for noticing!
Just pass the entire supplied command line, be it a single scalar or an array,
to system(). It'll do the right thing with it. This gets rid of a spurious
trailing space in debugging output when cmd() was called with a single scalar
as the command argument (leaving @cmdline undefined).
This ensures that TCP connections terminated through the CLAT gets a sensible
TCP MSS value negotiated. By default, the value is set to the MTU of the
defaultroute minus 40. There should be no reason to change this in the vast
majority of cases, but it can be overridden with the "v4-defaultroute-advmss"
setting.
Adds "v4-defaultroute-replace" config/command-line setting (default disabled).
When enabled, it will unconditionally disable the pre-flight IPv4 connectivity
check, and ensure that any pre-existing IPv4 default routes are removed during
startup (and presumably replaced with the one pointing to the CLAT, unless
"v4-defaultroute-enable" has been disabled). Any IPv4 default routes that were
removed in this manner are restored when clatd is shutting down.
Newer NetworkManager versions will run the dispatcher scripts when new
unknown interfaces show up, including 'clat'. That will cause a clatd
restart right after startup, and we'll never get to fully initialise. So
ensure the dispatcher script does nothing if the device in question is
our own 'clat' to prevent this.
