Cuckoo - namespace fixed (using Claude)

[0bacon 0]

Before we begin, I want to point out that I do not understand computer networking. It's so foreign to me that I can't wrap my head around it. After many hours, I turned to AI for assistance. I agree that the flaws within AI far outweigh the good. My work requires me to use AI, so I think it's ridiculous that I can't use the free version of Claude while my boss profits from it. I think that is hypocritical. Claude has helped me solve a range of issues, from incompatible library versions and bash scripting to a functioning Cuckoo. I provided Claude with the readme.md and my shell logs, and was immediately returned with a fix. I want to share what was found so that the AIRVPN Suite documentation or the Suite itself can be updated. 

The issue that I had was that Cuckoo did not have connectivity. While this fix might have been trivial to others, it's outside my understanding.

Here is Claude's fix
"
That confirms it exactly: routing works fine (ping by IP succeeds), but DNS is broken because resolv.conf inside aircuckoo points to 127.0.0.53 — the systemd-resolved stub, which only exists in your main namespace. Inside aircuckoo there's nothing listening on that loopback address, so every hostname lookup dies silently, which is exactly the "Failed to fetch" pattern you saw.

The fix is to give the aircuckoo namespace real, reachable nameservers instead of the stub resolver. Since network namespaces get their own loopback, create a namespace-specific override:
 

sudo mkdir -p /etc/netns/aircuckoo
sudo tee /etc/netns/aircuckoo/resolv.conf > /dev/null <<'EOF'
nameserver 1.1.1.1
nameserver 8.8.8.8
EOF

This is picked up automatically by ip netns exec for anything run in that namespace, without touching the main system's DNS config.
Then Test:

sudo ip netns exec aircuckoo getent hosts google.com

Relaunch Vivaldi:
cuckoo -r vivaldi
 

A couple of things to be aware of going forward:

• If Bluetit ever regenerates the namespace (e.g., after a systemctl restart bluetit), the /etc/netns/aircuckoo/resolv.conf file should persist since it lives outside the namespace itself, but worth re-testing after a restart just in case.
• You can swap 1.1.1.1/8.8.8.8 for whatever resolvers you prefer (your router's, or your ISP's).

"
This tells me there is a problem with having network lock enabled; the bluetit.rc has its default value. If I changed network lock persist to off, maybe that would have solved the problem? I won't bother changing it now; maybe if Cuckoo stops working, I'll try changing networklockpersist to off. I'm not going to pretend like I understand how a resolver works or how to configure a resolv.conf, be gentle. 

If you would like my logs or configurations, let me know. 

 

 

[Staff 10650]

Hello!

Thank you for reporting this and sharing the workaround. The distinction you found between working IP connectivity and failing hostname resolution is useful.

The explanation is consistent with a DNS configuration problem inside the namespace. 127.0.0.53 is systemd-resolved’s local DNS stub address. Since a network namespace has its own loopback interface, that address inside aircuckoo does not reach the resolver running in the main namespace. Unless a resolver is also listening inside aircuckoo, DNS requests sent there cannot succeed. See the systemd-resolved documentation.  https://www.man7.org/linux/man-pages/man8/systemd-resolved.service.8.html 

Providing reachable DNS servers through /etc/netns/aircuckoo/resolv.conf is therefore a reasonable workaround for the reported symptoms. The namespace-specific configuration mechanism is documented in ip-netns 
https://www.man7.org/linux/man-pages/man8/ip-netns.8.html, and Cuckoo also applies the namespace’s configuration files when launching an application.

Two clarifications:

• This does not establish that Network Lock caused the problem. Disabling networklockpersist would not make the main namespace’s loopback resolver accessible inside aircuckoo. There is no need to disable that protection to address this DNS issue. Also, the Suite 2.1.0 manual documents networklockpersist as off by default.
• Please do not assume the manual DNS override will survive namespace recreation. Bluetit manages this directory and can remove and regenerate its contents during the traffic-splitting lifecycle.

Cuckoo intentionally runs applications outside the VPN. DNS requests made to Cloudflare or Google through this configuration also follow the non-VPN path; choosing those resolvers changes who receives the queries.
To investigate why the stub address was selected, please share your distribution and Suite version, relevant traffic-splitting and Network Lock settings, and:

readlink -f /etc/resolv.conf
cat /etc/resolv.conf
cat /etc/netns/aircuckoo/resolv.conf
resolvectl status

The Bluetit startup log, particularly the “Found system … DNS” entries, would also help. Please remove credentials and other sensitive information before posting. There is no need to undo the working workaround.

Kind regards