How can I debug private networking functionality locally?

,
1

How can I debug private networking functionality locally? For instance, I want to debug how my fly.io app will interact with

http://somePrivateMachine.vm.somePrivateApp.internal:8080

I’ve connected to the fly.io wireguard network, but it still doesn’t work - when I attempt to make a request to the url, I still get the

Name or service not known

error.

3

This may have landed you in the organization’s default network, instead of somePrivateApp’s custom one, :cactus:…

How does somePrivateMachine’s IPv6 prefix compare with the DNS server’s, for example?

(The TXT _apps.internal test from the docs would be another way to check.)

4

Currently, the “private” app is still on the default network, it’s just not exposed to the internet.

5

Interesting… What does fly dig somePrivateMachine.vm.somePrivateApp.internal say?

Can you connect if you directly specify its numeric fdaa:* address (instead of a .internal name)?

Also, the two other checks from above would still probably help.

6

The private app does show up in the list printed by
dig _apps.internal TXT +short

Also, here’s the outcome of running the fly dig (I’ve replaced the app name and machine id with the placeholder in the below).

fly dig http://somePrivateMachine.vm.somePrivateApp.internal
;; opcode: QUERY, status: NOERROR, id: 53960
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;http://somePrivateMachine.vm.somePrivateApp.internal.	IN	 AAAA
7

Thanks… Leave off the http:// prefix on this one, though. (This is DNS-only.)

You should get its fdaa:* address at the end:

;; ANSWER SECTION:
somePrivateMachine.vm.somePrivateApp.internal.  5  IN  AAAA  fdaa:8:123:a7b:9876:ddbb:d11:2