Lumpiasty/klaster
0
0
Fork 0
Code Issues Pull Requests 2 Packages Projects Releases Wiki Activity

Get rid of NAT64 setup
ci/woodpecker/push/flux-reconcile-source Pipeline was successful
Details
ci/woodpecker/push/coredns-build Pipeline was successful
Details

Browse Source
This commit is contained in:
Lumpiasty
2026-06-16 00:29:18 +02:00
parent b993115b41
commit 679ebb3465
13 changed files with 316 additions and 419 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/network.md
+3 -8
View File
@@ -94,11 +94,7 @@ There are also networks, which are not VLANs, but are routed:
- Containers on CRS<br>
Access to every other network<br>
IP: 172.20.0.1/24, 2001:470:61a3:500::/64<br>
Static IP management, hosts Tailscale and CoreDNS (DNS64) containers
- NAT64 link on CRS<br>
Dedicated bridge for the Tayga NAT64 container<br>
IP: 192.168.239.0/30, fc64::/126 (link), 192.168.240.0/20 (Tayga dynamic pool)<br>
IPv6 traffic to 64:ff9b::/96 is routed here for translation to IPv4
Static IP management, hosts Tailscale and CoreDNS containers
Whole network is designed to eliminate VLANs, overlays where unnecessary to keep things simple. Only NAT rules are:
@@ -107,12 +103,11 @@ Whole network is designed to eliminate VLANs, overlays where unnecessary to keep
It doesn't have a gateway configured, we want to access it from other networks so we need to talk to it as if we were in the same subnet
- src-nat tailscale IPv6 to internet<br>
Tailscale assigns IPv6 from private subnet with no way to configure it, so the assigned IPs are not routable
- Masquerade Tayga NAT64 dynamic pool (192.168.240.0/20) via GPON PPPoE
- IPv4 port forwards from GPON PPPoE to respective services
## IPv6-mostly (NAT64/DNS64)
## DNS and IPv6 preference
LAN (vlan2) and IoT (vlan5) are IPv6-mostly networks (RFC 8925): clients capable of IPv6-only operation receive DHCP option 108, drop their IPv4 address, and activate CLAT using the NAT64 prefix advertised via PREF64 in router advertisements. Legacy clients keep dual-stack. DNS64 (CoreDNS container, with `translate_all`) synthesizes 64:ff9b::/96 AAAA answers so all named traffic exits via NAT64 (Tayga container) on our IPv4 WAN — bypassing the HE tunnel for egress and avoiding datacenter-IP captcha flagging. See [CoreDNS DNS64 + NAT64 design](./coredns-nat64.md) for details and deployment pitfalls.
DNS is served by a CoreDNS container (`172.20.0.3`); RouterOS forwards client queries to it. CoreDNS suppresses AAAA records by default so clients prefer IPv4, avoiding the HE tunnel's datacenter-flagged egress (which triggers CAPTCHAs on some sites). Our own zone (`lumpiasty.xyz`) and any explicitly whitelisted domains keep AAAA for native IPv6. See [CoreDNS resolver](./coredns.md). An earlier NAT64/IPv6-mostly approach to the same problem was built and abandoned; see the [postmortem](./nat64-dns64-postmortem.md).
There is also an UPnP and NAT-PMP enabled to automatically configure port forwards from LAN.