I don’t have a public IP assigned to this app because I do not want it publicly accessible, but I have assigned a private IP for Flycast. I can’t figure out any way to connect to it from my local machine. I’ve setup a WireGuard tunnel to Fly.io. I can query DNS and find the IP addresses of the 3 machines I have running CouchDB. But going to any of those IP’s on port 5984 in Arc (Chromium fork) or Safari doesn’t work. Using kitty-couchdb.internal:5984 also doesn’t work, and it’s the same for Flycast. I tried using curl in the terminal and that didn’t work either.
Looking at the logs, everything seems normal. There are some repeated errors about no _users database, but from what I can tell this is completely normal. If I ssh into a machine and do curl http://localhost:5984/_up everything is ok.
Forgot to mention I solved the first issue by setting it in fly secrets. The image takes COUCHDB_USER and COUCHDB_PASSWORD environment variables.
I was able to get everything working, almost. I’m able to connect to all 3 nodes I have running over WireGuard and look at them in Fauxton. When I try to set up replication between them though it always fails with stuff about DNS it seems.
Based on the output I’d think its something about auth, but I’ve reentered the password for the database being replicated from several times and I’m pretty sure it’s correct. Don’t have any other ideas really.
59 498.862588529 fdaa:3:3169:a7b:21a1:56cf:c280:2 → fdaa::3 DNS 109 Standard query 0x3019 AAAA fly.io OPT
60 498.864110074 fdaa::3 → fdaa:3:3169:a7b:21a1:56cf:c280:2 DNS 125 Standard query response 0x3019 AAAA fly.io AAAA 2a09:8280:1::a:791 OPT
The first is the request, and the second the response—with addresses in <source> → <destination> format. [It always surprises me initially to see those two get swapped in the second line, but it does make sense; for responses, it’s the server—fdaa::3—that’s sending.]
The part at the end of the first line, after the AAAA, might be illuminating in the case of the nxdomaining query. Perhaps there are lingering glitches in how IPv6-related things are being parsed/reconstructed.
Another possibility is a bypass of the fdaa::3 resolver, generally similar to what was mentioned in the following: