Debugging a Network Problem From Another Machine

Michael Placzek — Sat, 29 Aug 2026 13:00:00 +0000

One of the most useful questions in network troubleshooting is also one of the simplest:

Does it fail from another machine too?

If a website will not load on my laptop, trying it from another computer can immediately change the investigation.

If it works there, the service probably is not down. Something about my machine, DNS configuration, VPN, firewall, route, or network path is different.

If it fails there too, the problem may be farther upstream.

I wanted Network Doctor to be able to ask that question directly.

So I added remote diagnosis over SSH.

netdoc --via ideapad github.com

Instead of running the diagnosis locally, Network Doctor connects to ideapad, runs the checks there, and reports the result back on my machine.

Why another vantage point matters

A network failure is always observed from somewhere.

Suppose github.com is unreachable from my workstation.

I can test DNS:

dig github.com

Then TCP:

nc -vz github.com 443

Then TLS:

openssl s_client -connect github.com:443

Maybe I inspect my routes, VPN, proxy settings, or firewall.

Those tests are useful, but they all share one property: they are observing the network from the same machine.

Trying the same destination from another machine gives me a new piece of evidence.

Imagine this:

Thelio:
DNS       PASS
TCP 443   FAIL

Ideapad:
DNS       PASS
TCP 443   PASS
TLS       PASS
HTTPS     PASS

That difference is interesting.

GitHub clearly is not universally unreachable. The second machine just reached it.

Now I have a much smaller problem to investigate: what is different about the path from Thelio?

That is often more useful than running another five commands on Thelio.

Turning that into a command

Network Doctor already runs network checks as a dependency graph.

For an HTTPS target, for example, it can test things such as the local interface, DNS resolution, TCP connectivity, TLS, HTTP, routing, and path MTU.

Normally:

netdoc github.com

means:

Diagnose github.com from this machine.

With --via:

netdoc --via ideapad github.com

it becomes:

Diagnose github.com from ideapad.

The SSH machine is the vantage point. My local machine is just controlling the run and displaying the result.

That distinction becomes especially useful with service profiles.

For example:

netdoc --via ideapad --profile github

The GitHub profile independently checks GitHub's website, API, normal SSH endpoint, and alternate SSH endpoint.

So I can ask a more useful question than simply "can the other computer ping GitHub?"

I can ask whether the actual service paths I care about work from there.

It also works across operating systems

One of my tests involved a Linux workstation controlling a Windows machine over SSH.

The command was still just:

netdoc --via ideapad --profile github

The remote worker ran on Windows, while I launched and viewed the diagnosis from Linux.

I like this because the two machines do not need to be identical.

In fact, sometimes it is more interesting when they are not.

A Windows laptop and a Linux workstation might have different DNS configuration, routes, VPN software, firewall rules, interfaces, or network locations.

Those differences are exactly what can make a second vantage point useful.

This is not just "run the command over SSH"

I could obviously do this:

ssh ideapad netdoc github.com

And sometimes that is perfectly sufficient.

The reason I wanted remote execution inside Network Doctor is that the location of the probe becomes part of the diagnostic model.

That means the same mechanism can be used with profiles and structured output instead of treating the remote command as an unrelated terminal session.

For example:

netdoc --via ideapad --profile github

still means "run the GitHub diagnostic profile," while ideapad answers the separate question of where those probes should originate.

I think that separation is useful:

What should I test?     --profile github
Where should I test it? --via ideapad

What this can tell you

A second vantage point does not magically identify every network problem.

But it can eliminate a lot of possibilities quickly.

If the same destination fails from both machines in the same way, that is evidence that the issue may not be specific to one host.

If it fails from one machine but works from another, host-specific or path-specific explanations become much more interesting.

If DNS answers differ, investigate DNS.

If DNS agrees but TCP connectivity differs, look farther down the path.

If TCP succeeds from both but TLS fails from only one, that is another useful distinction.

The important part is not simply having more probes.

It is having different observations that can disagree.

Disagreement is often where the useful information is.

The larger idea

Network troubleshooting tools usually become collections of tests:

ping something.

Resolve something.

Open a socket.

Inspect a route.

Check a certificate.

Those are necessary, but I am increasingly interested in the reasoning that connects the observations.

A diagnostic tool should help answer:

What does this result rule out?

Remote diagnosis adds another way to obtain that evidence.

Instead of endlessly probing the same broken machine, sometimes the best next probe is the same test from somewhere else.

That is now one command in Network Doctor:

netdoc --via another-machine target

Network Doctor is open source, and I would especially like to hear about cases where comparing two machines gives a misleading result or where the remote diagnosis reaches the wrong conclusion.

Those are the interesting bugs.

https://github.com/heymaikol/network-doctor