Chameth.com - posts like debugging-beyond-the-debugger, exposing-game-servers-over-tailscale, why-you-should-be-using-https but not tracking-pbs-without-the-dark-patterns

An interesting Tailscale + Docker gotcha

2026-01-29T00:00:00Z

As I’ve written about before, I use Tailscale for a lot of things. I thought I had it set up in a reasonably secure manner, but I recently noticed a problem.

I use Tailscale’s ACLs to limit what each node can access, based on the tags I apply to it. So an app node can’t access anything via Tailscale, while an integration or server node can access things tagged with either app or integration. This is expressed pretty simply in the Tailscale ACL JSON:

{
	"tagOwners": {
		// Servers that can be SSH'd into
		"tag:server": [],
		// Applications that are exposed on tailscale but never connect out
		"tag:app": [],
		// Things which talk to other services over tailscale (connecting to apps etc)
		"tag:integration": [],
	},
	"grants": [
		{
			// Users can access everything
			"src": ["autogroup:member"],
			"dst": ["*"],
			"ip":  ["*"],
		},
		{
			// Servers and integrations can access integrations and apps
			"src": ["tag:server", "tag:integration"],
			"dst": ["tag:integration", "tag:app"],
			"ip":  ["*"],
		},
	],
}

Over the past week I’ve been setting up a private Forgejo instance behind Tailscale, complete with an actions runner that runs things using a docker-in-docker container. I didn’t want the runner knowing anything about Tailscale, so I had it configured to speak to Forgejo direct over HTTP (forgejo:3000) instead of using full Tailscale HTTPS URL that I use when accessing it (http://git.example-net.ts.net/)¹.

Everything was going fine, until I forgot to do that translation… and it worked. My Forgejo action runners could access anything on my tailnet. I run several things on Tailscale that just have authentication turned off, on the basis that only authorised devices can access them. Things like the admin interface for this website. I definitely didn’t intend for any workflow I run on my git server to have access to edit my website!

This wasn’t just limited to Forgejo, either. Any docker container I was running could access the tailnet. In hindsight it’s fairly obvious why: the host is running Tailscale, connected as a node tagged with my server tag. That creates a tailscale0 interface, and automagically sets up iptables rules to route Tailscale traffic over the interface. Docker also automagically sets up iptables rules to bridge traffic, and apparently these two sets of rules interact in such a way that traffic from Docker containers is allowed to route via the tailscale0 interface.

I say it’s fairly obvious in hindsight — there’s no reason why Docker would special case any particular host interface after all — but it still feels pretty surprising. Because both bits of software inject their own iptables rules, I never really had a good mental model for how they interact. The host Tailscale node was a completely separate building block to Docker. It would be a pain to use either of them if they didn’t do these rules, but it’s also one of the reasons I don’t really like “magical” things².

There are lots of ways to fix this, but none of them feel particularly great. You can configure both Tailscale and Docker to not automatically fiddle with iptables and handle the rules yourself, but I really hate dealing with iptables³. As a stopgap I did hold my nose and add some iptables rules to drop traffic to the tailscale0 interface if it originated from the IP ranges that Docker was configured to use:

iptables -I DOCKER-USER -s 192.168.0.0/16 -o tailscale0 -j DROP
iptables -I DOCKER-USER -s 172.17.0.0/12 -o tailscale0 -j DROP

The DOCKER-USER chain is a nice little escape hatch; it comes before the main auto-generated DOCKER chain, and Docker leaves the rules in it alone.

So I added these rules, and felt pretty good about myself, and then… everything started breaking in weird ways. After some debugging I realised the problem was DNS⁴. The server’s DNS resolver is 100.100.100.100, a special Tailscale address. This is so that it can resolve tailnet hostnames via MagicDNS (and so I don’t have to configure my custom DNS servers manually on each device; Tailscale does it for me). My new iptables rules inadvertently dropped all the DNS packets coming from docker containers. D’oh.

Obviously the solution here is to double down and add MORE iptables rules:

iptables -I DOCKER-USER -s 192.168.0.0/16 -d 100.100.100.100 -o tailscale0 -j ACCEPT
iptables -I DOCKER-USER -s 172.17.0.0/12 -d 100.100.100.100 -o tailscale0 -j ACCEPT

This got DNS working again, but it all feels a bit gross. Not least because to actually make these persist you need to use iptables-save, and then you also get all the rules that both Docker and Tailscale have inserted. I came across a script to filter out the Docker ones, but… yuck⁵.

I realised a cleaner idea might just be to lock down what server tagged nodes could access within Tailscale itself. That way I can avoid touching iptables at all. It’s handy to be able to curl services from the host when debugging, but it’s not really necessary. So I removed that access, and… stuff broke again. I’m using my Forgejo instance as a registry for some of the docker images I run, so the docker daemon needs to be able to reach it. I ended up making a new tag for infrastructure, which can be accessed from server devices. This does still allow all the docker containers to reach Forgejo, but I already have it set up with appropriate access controls and public/private repository splits. Forgejo is a service designed to run publicly, so this seems a reasonable trade-off for convenience. I used the tests feature of Tailscale’s ACL config to make sure I’d got the rules right:

{
	"tests": [
		{
			// Servers can only access infrastructure
			"src":   "tag:server",
			"proto": "tcp",
			"allow": [
				"tag:infrastructure:8080",
			],
			"deny": [
				"100.84.16.43:8080",
				"me@example.com:8080",
				"tag:server:8080",
				"tag:app:8080",
				"tag:integration:8080",
			],
		},
	],
}

The whole situation still feels a bit messy. If I ever get around to switching to nftables I might loop back and manually craft some rules for routing traffic, instead of leaving Tailscale and Docker to do their own thing.

I discovered later on that logging into the container registry at forgejo:3000 actually issued a redirect to https://git.example-net.ts.net/ so this was all basically for naught… ↩︎
I didn’t use Tailscale’s MagicDNS for a long time just because the word “magic” put me off. Only when I eventually got around to learning how it worked, and seeing that it wasn’t really that magical under the hood, did I change my mind. ↩︎
nftables seems far better in lots of ways, but I can’t really be bothered migrating. Maybe next time I reimage the server for whatever reason… ↩︎
It’s always DNS… ↩︎
Again, nftables would almost certainly help here. It actually has (gasp) configuration files. But again, I really didn’t want to spend the time migrating. ↩︎

Exposing game servers over Tailscale

2025-12-07T00:00:00Z

I’ve recently been playing a lot of Factorio with a friend. I’ve been hosting, but my desktop computer is behind far too many layers of NAT, and I can’t be bothered dealing with setting up port forwards. Up until today we made do with Steam’s networking support, which in our case ended up relaying the connection via one of their servers. This is amazing as a free, no-hassle service, but the performance was so-so. We’d get random lag spikes, or the initial map download would crawl along at about 1/100th of the speed we should be able to get. We’re both fans of Tailscale though, so maybe there’s an easy solution there?

Tailscale even have an article on sharing a Factorio server but it’s a ten minute long video¹, and focused on setting up an actual dedicated server in Docker rather than just clicking the convenient “Host” button in the game client. What we did instead was:

I shared my desktop’s Tailscale node with my friend, by creating a sharing link in the Admin console
My friend accepted the link, and could then see my machine in their admin panel
I used tailscale lock to sign my friend’s desktop’s node key, as I have tailnet lock enabled
I added a grant to my tailnet’s ACL to permit access from my friend to the specific IP/port on my tailnet:

		{
			"src": ["friend@example.com"],
			"dst": ["100.0.0.42", "fd7a::42"],
			"ip":  ["udp:34197"],
		}

After this, my friend could connect to Factorio by entering the Tailscale IP address, or the Tailscale hostname (as they use MagicDNS). Running tailscale status shows that Tailscale managed to establish a direct connection despite the many layers of NAT involved, and the performance improvements were significant and immediate.

We did a bit of testing, and confirmed that no other services on my machine are accessible. And sharing a machine by default only allows it to accept incoming connections, so I can’t get unwanted access to anything on my friend’s Tailnet, either.

I’ve written before about all the different ways I use Tailscale; this is yet another new way it’s solved a problem for me.

I’m not a fan of video tutorials at the best of times, but especially not when I want to do something as quickly as possible so I can get back to ~~my addiction~~ growing the factory. ↩︎

Avoiding the Consequences of Dumb Laws with Tailscale

2025-09-30T00:00:00Z

More and more sites are implementing privacy-invading age checks or just completely blocking the UK thanks to the Online Safety Act.

Protecting kids from some content online is certainly a noble goal, but the asinine guidance from Ofcom, threats of absolutely disproportionate fines, and the stupidly broad categories of content have resulted in companies just giving up or going through a tick-box exercise that offers very little protection but lots of inconvenience and a complete invasion of privacy.

Instead of uploading my ID to some third party company, I’ve taken to proxying my traffic through to a country that doesn’t have such stupid laws. Thankfully, Tailscale makes this really easy. I’ve discussed how I use Tailscale before, but not really covered app connectors. I find Tailscale’s description of these pretty confusing, but they basically amount to automatic, DNS-based subnet routing configurations (or, to put it another way, a per-website exit node). You can safely ignore all references to ‘SaaS apps’ in their docs.

I create a custom app connector, and give it the domains to be included:

App configuration in the Tailscale admin console

Tailscale then magically resolves those domains, and has the ‘connector’ advertise routes for them. Any client that accepts routes will start sending requests to the connector, which passes them onto the Internet at large. Any other traffic is left alone, unlike when you use an exit node.

The special bit here is how you can specify wildcard domains. Tailscale proxies the DNS requests from clients (so it can inject responses for nodes on your tailnet), which means it can dynamically update the routes as you resolve new domains. I tried to set this up more manually, and quickly came unstuck: despite using the same DNS servers, my server and my desktop would get different responses for the same query as it varied by geography. Trying to get the full set of IPs (and keeping them updated) would have been a nightmare. Tailscale expanding the wildcards nicely sidesteps all of that.

At first I was just proxying the traffic to one of my servers, but just today I added a new connector for Imgur and found I was still blocked, just for different reasons. They not only block my entire country but also a load of known datacenter IP ranges. Hmph. I fixed this by hacking up a new side project: tsv. It’s a simple Go app that accepts traffic from the tailnet (advertising itself as both an app connector and an exit node), and passes it on to another VPN.

There are lots of other ways you could accomplish this, but this makes it so all my devices can still access services without any additional configuration. As long as Tailscale is installed, the Internet will still work as it’s meant to, without all the nonsense. If I come across a site that doesn’t work, adding it is trivial: I just make a new app connector in Tailscale.

Obvious disclaimer: the laws in the UK are binding on the service providers, not the end user. Doing this sort of thing in other countries might be illegal. I don’t know; do your own research! Also all of this is a workaround for something that should be fixed at a legislative level, but I’m not holding my breath.

How I use Tailscale

2025-06-25T00:00:00Z

The Tailscale logo

I’ve been using Tailscale for around four years to connect my disparate devices, servers and apps together. I wanted to talk a bit about how I use it, some cool features you might not know about, and some stumbling blocks I encountered.

I’m not sure Tailscale needs an introduction for the likely audience of this blog, but I’ll give one anyway. Tailscale is basically a WireGuard¹ orchestration service, with lots of nice features sprinkled on top. It’s a subscription product, but it has an insanely generous free tier that covers basically anything you’d ever want to do as an individual. They also open source all their client software, and there’s a third party control server implementation called Headscale if you want to avoid the hosted system entirely.

Basic connectivity

At its core, Tailscale lets you easily connect from one device to another, even if they’re not directly exposed to the Internet. You install the Tailscale client wherever you like (on your phone, computer, servers, Raspberry Pi, etc), authenticate the machine with the control server, and it can then talk to all the other machines on the tailnet using their private Tailscale IP addresses.

That isn’t anything revolutionary: it’s the basic premise behind VPNs. But Tailscale makes it so easy. You don’t have to bother with any networking configuration. You don’t have to distribute keys. You just install the client², and login.

For example, my home automation service runs on a Raspberry Pi that sits behind two different routers. I installed Tailscale on it³, logged in, and immediately I could SSH into it from my computer or my phone even when they’re on different networks.

Speaking of SSH, Tailscale has special support for it whereby it handles any incoming connection to port 22 from the Tailscale network, and deals with authentication itself. No public keys or passwords: if you’re logged into Tailscale you can be logged into the machine. This is particularly handy when you SSH from a phone, as proper credential management is a bit of a nightmare there.

Exposing entire machines is just the start, though. If you run multiple services on the machine you need to remember which port they’re all on. Yuck. Instead, you can expose individual services as their own node on a tailnet. There are lots of options for doing so: there’s an official Docker image, a Go library, and many third-party tools (such as my own Centauri and tsp).

Not just a VPN

Exposing individual services wouldn’t be much use if you still had to remember their IP addresses. For a long time I manually added DNS entries for Tailscale nodes, allowing me to connect to http://grafana/ instead of http://100.73.190.100. Recently I switched to Tailscale’s MagicDNS, though, which takes care of that for you. Every machine on the tailnet gets an automatic DNS entry based on its name.

I initially shied off of this because it changes the DNS resolver on every machine it’s installed on, and it all seemed a bit too “magic” for me⁴. I got fed up with manually adding DNS entries though, so I spent a bit of time learning about it and got over my knee-jerk “what on earth is going on?!” reaction. The DNS controls also let you force a specific upstream DNS server. I use NextDNS everywhere, so having Tailscale automatically configure this for me on all my devices was a bonus⁵.

As well as the short names, you can resolve nodes on the tailnet using a slightly longer form: machine.your-tailnet.ts.net. The “your-tailnet” bit is randomly generated, and you can reroll it in the control panel to find a fun one. But why waste time say lot word, when few word do trick? Because Tailscale can make these addresses globally routable, and issue TLS certs for them too.

Say you’re developing something on your local machine, and want to get feedback from someone. You can use Tailscale’s “funnel” feature to expose it publicly:

tailscale funnel 127.0.0.1:8080

With no other options, this will expose the service over HTTPS on port 443. You can then invite people to visit https://machine.your-tailnet.ts.net and they’ll connect through to port 8080 on your machine. They don’t even need Tailscale installed. I don’t use this terribly often, but it’s a great quality-of-life improvement on the occasions I do want to share something.

Tailscale also has a “serve” command, which does much the same but only exposes it over your tailnet. This is how you’d use the Tailscale Docker image to expose a normal service onto your tailnet, but it’s also useful for similar development scenarios. Occasionally I’ll want to test something on my phone, and rather than make sure it’s connected to the right Wi-Fi network, recompiling the app to not bind to localhost, figuring out my machine’s IP, and so on, and so forth, I just run tailscale serve and access it over Tailscale.

Authentication, two ways

One of my minor frustrations with Tailscale was how cumbersome the authentication process was. I logged in using GitHub, and every time I tried to login to Tailscale, I had to bounce through the GitHub OAuth flow and then select which organisation I wanted to use. Even if I was logged in to GitHub, it still shows the permission page every time. It’s not a dealbreaker, but it’s definitely not smooth. This is what it looks like:

Logging in to Tailscale with a GitHub account

Tailscale have since added the ability to sign in with a custom OIDC provider, so I set up a KeyCloak instance, and my login flow now looks like this:

Logging in to Tailscale with KeyCloak as an OIDC provider

It’s a significantly shorter flow, and because KeyCloak is entirely under my control I can configure how long I stay logged in for. It also reduces my reliance on third parties: if GitHub goes down, or decides to ban my account⁶ or something, I can still access Tailscale.

That’s how you log in to Tailscale, but Tailscale can also assist with logging in to other services. If you connect to a HTTP service over Tailscale, it will add in the following headers:

Tailscale-User-Login: alice@example.com
Tailscale-User-Name: Alice Smith
Tailscale-User-Profile-Pic: https://example.com/photo.jpg

A lot of software has support for accepting login credentials provided by a reverse proxy, which is basically what’s happening here. For example, I run a Grafana instance that’s only exposed over Tailscale. Its config (set in environment variables) is:

GF_USERS_AUTO_ASSIGN_ORG: "true"
GF_USERS_AUTO_ASSIGN_ORG_ROLE: "Admin"
GF_AUTH_PROXY_ENABLED: "true"
GF_AUTH_PROXY_HEADER_NAME: "Tailscale-User-Login"
GF_AUTH_PROXY_HEADER_PROPERTY: "email"
GF_AUTH_PROXY_AUTO_SIGN_UP: "true"

So anyone who presents a Tailscale-User-Login header gets an admin account created with that as their e-mail address. It’s super convenient, but obviously make sure it’s only exposed via Tailscale if you do that!

Other services I run that support this include Miniflux (an RSS reader), Jelu (a book tracker), Linkding (a bookmark manager), and Seafile (a file storage system). If you’re hosting something yourself, look out for “proxy auth” or “remote users” in the documentation or configuration. It’s amazingly convenient to be able to access things without entering credentials.

ACLs, tags and mistakes

For a long time I didn’t bother with any kind of ACLs within my Tailscale network. Every machine could access every other machine. Then one day a thought hit me. The default Tailscale SSH config re-prompts you for user authentication, but I’d disabled that by tweaking the config… That means anyone with access to any of my machines (or who managed to get Tailscale credentials out of one of my apps) would be able to SSH into anywhere else on my network. Even as root! Compromising a small bit of my network would immediately lead to a complete take-over. What’s the point in defence-in-depth if you roll out a red carpet over the drawbridge for any attackers?

The first and most obvious fix for this was to restrict root access over SSH. I changed my Tailscale ACL to prompt for reauthentication for root access, but still allow regular SSH unprompted:

{
  "ssh": [
    {
      "action": "accept",
      "src":    ["autogroup:member"],
      "dst":    ["autogroup:self"],
      "users":  ["autogroup:nonroot"],
    },
    {
      "action": "check",
      "src":    ["autogroup:member"],
      "dst":    ["autogroup:self"],
      "users":  ["root"],
    },
  ],
}

This still didn’t sit right with me, though. Why should a random webserver be able to (theoretically) SSH into my desktop computer unchallenged? Tailscale allows you to do more advanced ACLs by applying tags to devices. I dutifully created a bunch of tags, and went through and tagged every device: user, server, app, container, and so on. This, it turns out, was a mistake. I could no longer SSH to anywhere. If I’d read the docs properly, I might have noticed how they describe tags:

Tailscale tags are how you authenticate and identify non-user devices, such as servers and ephemeral nodes. They serve two primary purposes: to provide an identity to non-user devices and to let you manage access control policies based on purpose.

By applying a nice user tag to all of my devices (computer, phone, tablet and so on), I’d effectively removed my own identity from them. They no longer counted for the autogroup:member source in the SSH config. Whoops. And it’s not easy to fix either:

You cannot remove all tags from a device. A device with a tag-based identity must have at least one tag.

So I’d have to remove all the affected devices, then re-add them. At the time I wanted to roll back all the tags, which would mean reconnecting dozens of nodes to the Tailnet. I did end up doing that, but I also took it as an opportunity to switch to KeyCloak as I mentioned earlier. Setting everything up again was a bit less painful when it wasn’t just correcting a dumb mistake.

I now have a much more sensible tag setup: servers are tagged server, apps are tagged app, and a few special apps are tagged integration. I then use Tailscale’s grants to limit access within the tailnet:

{
  "grants": [
    {
      // Users can access everything
      "src": ["autogroup:member"],
      "dst": ["*"],
      "ip":  ["*"],
    },
    {
      // Servers and integrations can access integrations and apps
      "src": ["tag:server", "tag:integration"],
      "dst": ["tag:integration", "tag:app"],
      "ip":  ["*"],
    },
  ],
}

This stops anyone but a user device from accessing servers, and stops plain apps from accessing anything at all. So for example my Grafana instance is tagged as an app; it doesn’t connect out over Tailscale for anything, it only exposes its interface over Tailscale. My home automation software is tagged as an integration, as it reaches out to other services over Tailscale (e.g., to push metrics it receives from devices).

You could go even further and limit which specific machines talk to which others, but I think this tier system sets reasonable boundaries for my use without getting too much in the way.

Even more

There are lots of other cool features offered by Tailscale that I’ve not covered: exit nodes (allowing you to route normal Internet traffic over Tailscale; very handy when you’re behind a router you don’t trust, or if you want to appear as being in another country for totally legitimate reasons); Tailscale lock (a system where existing nodes have to verify any new ones, guarding against both unauthorised access and Tailscale themselves inserting nodes into your network); file sharing, and more I’ve probably forgotten.

As I mentioned before, an awful lot is available on the free personal plan. It’s definitely worth checking out if you manage servers, or self-host anything. I can’t imagine going back to managing servers and private apps without Tailscale, and I’m excited to see what else they do going forward.

If you’re not familiar with it, WireGuard is a modern VPN included in the Linux kernel. It’s basically the only VPN that isn’t terrible. ↩︎
They have installation instructions and packaged versions of the client for just about every device you can imagine: Windows, Mac, every major Linux distribution, iOS, Android, etc, etc ↩︎
They even have an apt repository specifically for raspbian builds, so it’s super easy. ↩︎
Lots of people seem to treat “magic” as a good thing in software. I think it’s the absolutely opposite. I want to know how something works, not for it to be inscrutable! ↩︎
This is entirely optional, of course, you can just let each device do their own thing as well. ↩︎
I don’t think this is likely, but it’s one of my biggest concerns about using “social” logins. More-or-less all of these services can arbitrarily ban you with no recourse; why would you trust them as keyholders to other things? ↩︎

Debugging beyond the debugger

2019-05-08T00:00:00Z

Real-life debugging tools

Most programming — and sysadmin — problems can be debugged in a fairly straight forward manner using logs, print statements, educated guesses, or an actual debugger. Sometimes, though, the problem is more elusive. There’s a wider box of tricks that can be employed in these cases but I’ve not managed to find a nice overview of them, so here’s mine. I’m mainly focusing on Linux and similar systems, but there tend to be alternatives available for other Operating Systems or VMs if you seek them out.

Networking

tcpdump

tcpdump prints out descriptions of packets on a network interface. You can apply filters to limit which packets are displayed, chose to dump the entire content of the packet, and so forth.

Typical usage might look something like:

# tcpdump -nSi eth0 port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:03:35.577781 IP6 2001:db8::1.54742 > 2001:db8::2.80: Flags [S], seq 2815779044, win 64800, options [mss 1440,sackOK,TS val 2378811665 ecr 0,nop,wscale 7], length 0
16:03:35.586853 IP6 2001:db8::2.80 > 2001:db8::1.54742: Flags [S.], seq 1522609102, ack 2815779045, win 28560, options [mss 1440,sackOK,TS val 3063610173 ecr 2378811665,nop,wscale 7], length 0
16:03:35.586877 IP6 2001:db8::1.54742 > 2001:db8::2.80: Flags [.], ack 1522609103, win 507, options [nop,nop,TS val 2378811674 ecr 3063610173], length 0
16:03:35.620678 IP6 2001:db8::1.54742 > 2001:db8::2.80: Flags [P.], seq 2815779045:2815779399, ack 1522609103, win 507, options [nop,nop,TS val 2378811708 ecr 3063610173], length 354: HTTP: GET / HTTP/1.1

Here you can see the start of a plaintext HTTP request: the three-way handshake as the TCP connection is established followed by a GET request. Even if the data is encrypted as it will be in most cases, it’s often useful to see the “shape” of the transmissions: did the client start sending data when it connected, did the server ever respond, etc.

Daniel Miessler has a good tutorial on tcpdump if you’re not familiar with it and don’t want to jump straight into the man page.

… with Docker

Docker sets up separate network namespaces for each container. To see the traffic across the interfaces of a single container you can nsenter the container’s network namespace:

# nsenter -t $(docker inspect --format '{{.State.Pid}}' my_container) -n tcpdump -nS port 80

This retrieves the PID for the container, and tells nsenter to enter the network (-n) namespace from the given target (-t) PID, and then run the given command (in this case tcpdump ...).

openssl s_client / s_server

When a connection is using TLS it’s often useful to try connecting to the server and see what certificate it presents, algorithms it negotiates, and so forth. OpenSSL offers two useful subcommands which can help with this: s_client for connecting as a client, and s_server for listening to connections.

For example, using s_client to connect to google.com on the standard HTTPS port shows us details about the server cert and its verification status:

$ openssl s_client -connect google.com:443
CONNECTED(00000003)
depth=2 OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
verify return:1
depth=1 C = US, O = Google Trust Services, CN = Google Internet Authority G3
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.google.com
verify return:1
---
Certificate chain
 0 s:C = US, ST = California, L = Mountain View, O = Google LLC, CN = *.google.com
   i:C = US, O = Google Trust Services, CN = Google Internet Authority G3
 1 s:C = US, O = Google Trust Services, CN = Google Internet Authority G3
   i:OU = GlobalSign Root CA - R2, O = GlobalSign, CN = GlobalSign
---
# ...

Whereas connecting to my webserver and providing an unknown host in the SNI field results in an SSL alert 112 (“The server name sent was not recognized”) and no server certificate is sent:

$ openssl s_client -connect chameth.com:443 -servername example.com
CONNECTED(00000003)
140384831313024:error:14094458:SSL routines:ssl3_read_bytes:tlsv1 unrecognized name:../ssl/record/rec_layer_s3.c:1536:SSL alert number 112
---
no peer certificate available
---
# ...

Often if you hit this kind of alert in an application the exact error will be lost somewhere in the many layers between the SSL library and the logs, so being able to directly connect and test can help diagnose a lot of issues.

Once a connection is established you can read and write plain text and it will be encrypted and decrypted automatically.

Java apps

If a Java app is involved in the connection, you can enable a lot of built-in debugging with a simple JVM property: javax.net.debug. You can tweak what exactly gets logged, but the easiest thing to do is just set the property to all and you’ll see information about certificate chains, verification, and packet dumps:

$ java -Djavax.net.debug=all -jar ....
# ...
found key for : duke
chain [0] = [
[
  Version: V1
  Subject: CN=Duke, OU=Java Software, O="Sun Microsystems, Inc.",
  L=Cupertino, ST=CA, C=US
# ...

More information about Java’s debugging options is available on docs.oracle.com.

Thread and core dumps

Higher-level languages frequently provide an interactive way to dump the current execution state of all of their threads (a “thread dump”). This is useful to spot deadlocks, some types of race conditions, and as a quick and dirty method of investigating hangs or excessive CPU usage.

With both Java and Go applications you can send a QUIT signal to have a thread dump printed out; Go applications will quit after doing so, Java ones will carry on running. At most terminals you can hit Ctrl and \ to send a QUIT signal.

For Java you can also use the jstack tool from the JDK to dump threads by PID; this can be useful if the application is running in the background or has redirected sysout:

$ jstack 8321
Attaching to process ID 8321, please wait...
Debugger attached successfully.
Client compiler detected.

Thread t@5: (state = BLOCKED)
 - java.lang.Object.wait(long) @bci=-1107318896 (Interpreted frame)
 - java.lang.Object.wait(long) @bci=0 (Interpreted frame)
 - java.lang.ref.ReferenceQueue.remove(long) @bci=44, line=116 (Interpreted frame)
 - java.lang.ref.ReferenceQueue.remove() @bci=2, line=132 (Interpreted frame)
 - java.lang.ref.Finalizer$FinalizerThread.run() @bci=3, line=159 (Interpreted frame)

# ...

A core dump provides more complete information about the state of a process, but is often more complex to interpret. The gcore utility from GDB will create a core dump of a process with a given PID. You can then generally load the core file using your normal debugger, depending on the language in question.

System calls

strace is the swiss army knife for seeing what a process is doing. It details each system call made by a program (you can filter them down, of course). For example:

$ strace -e read curl https://google.com/
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0 \236\0\0\0\0\0\0"..., 832) = 832
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0P!\0\0\0\0\0\0"..., 832) = 832
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200l\2\0\0\0\0\0"..., 832) = 832
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\20Q\0\0\0\0\0\0"..., 832) = 832
# ...
read(3, "\0\0\0\0\0\0\0\4\25\345\366\302\273sE6\365wI\225\321|\3435Z\362\216\372\215\251aO"..., 253) = 253
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://www.google.com/">here</A>.
</BODY></HTML>
read(3, "\27\3\3\0!", 5)                = 5
# ...

Brendan Gregg has a nice guide on strace and alternatives.

… with docker

When the application is running in docker you can usually just strace it from the host with the correct PID (from e.g. docker inspect --format '{{.State.Pid}}' my_container). Sometimes you may need to trace the startup of an application though, which is a bit trickier. Instead you can run a new container using the same PID namespace as your target, and the permissions needed to strace:

$ docker run --rm -it --pid=container:my_container \
  --net=container:my_container \
  --cap-add sys_admin \
  --cap-add sys_ptrace \
  alpine

From within the new container you can install strace, and trace any running program within the target container using strace -p as normal. To start a new program you need access to the target container’s filesystem, which you can get to via /proc/1/root (PID 1 being the main process that docker started in the target container).

Files

Sometimes the problem might relate to file access. There are a couple of straight forward — but nonetheless useful — tools which might help here. inotifywait uses the Linux inotify subsystem to watch files or directories for operations. For example:

$ inotifywait -mr site/content
Setting up watches.  Beware: since -r was given, this may take a while!
Watches established.
site/content/post/ MODIFY 2019-05-08-debugging-beyond-the-debugger.md
site/content/post/ OPEN 2019-05-08-debugging-beyond-the-debugger.md
site/content/post/ MODIFY 2019-05-08-debugging-beyond-the-debugger.md
site/content/post/ MODIFY 2019-05-08-debugging-beyond-the-debugger.md
site/content/post/ CLOSE_WRITE,CLOSE 2019-05-08-debugging-beyond-the-debugger.md
# ...

Here the -m switch makes inotifywait monitor the files forever (instead of exiting on the first modification, which is the normal behaviour) and r makes it recurse into the directory and monitor each file and subdirectory in there.

If you want to see what processes currently have a file open, fuser is the go-to tool. For example:

$ fuser -v /
                     USER PID ACCESS COMMAND
/:                   root     kernel mount /
                     chris      2961 .rc.. systemd
                     chris      2986 .r... gdm-x-session
                     chris      2994 .r... dbus-daemon
                     chris      3001 .r... gnome-session-b
# ...

Honourable mentions

These aren’t really debugging tools, but I feel it’s worth mentioning as they often feature somewhere along the debugging-of-weird-problems journey.

I’ve seen some weird and wonderful problems happen because a disk is full, so a quick df early on in the debugging process never hurts. Some apps may hang, some may corrupt their config, some may fall over and die; sometimes the manner in which they fail doesn’t obviously point to a disk space issue.

Another issue that comes up now and then — especially inside VMs or other environment that don’t have a decent amount of “noise” happening — is entropy exhaustion. A quick look at /proc/sys/kernel/random/entropy_avail should be enough to confirm that everything is ticking along nicely. If it’s exceedingly low then you may find that anything involving random number generation stalls (TLS connections for example).