Diagnose TCP/IP Connectivity One Layer at a Time

When a graduate engineer is asked to “check the network” or “confirm a service is reachable”, the request is rarely as simple as it sounds. TCP/IP

This guide builds that skill from first principles using read-only, non-destructive commands that are safe to run repeatedly. Because the assignment brief does not specify a known production environment, every exercise here assumes an isolated or non-production lab with confirmed permissions, consistent with the experience assumptions declared for this task. The aim is not to memorise a checklist of commands, but to understand what each one actually proves, what it does not prove, and how to recover safely and escalate correctly when the evidence is ambiguous or the fault sits outside your authority.

#Learning Objectives

• Explain the TCP/IP layers relevant to a connectivity task and what each layer’s evidence does and does not prove.
• Distinguish network-layer reachability (ICMP) from transport-layer service availability (TCP) using observable command evidence.
• Design and run a bounded, non-destructive validation exercise with explicit pass, stop and cleanup conditions.
• Diagnose common TCP/IP failure modes by symptom, probable cause and safe corrective action.
• Recognise the permissions, security boundaries and escalation points required before extending this pattern to production.

#Prerequisites

• Access to an isolated or non-production validation environment (lab VMs, containers, or a sandboxed segment).
• Confirmed product/tool version and account permissions before applying any change or running diagnostic commands.
• Basic familiarity with command-line interfaces on Linux
  The KBY Lexicon

  Linux

  Linux is the open-source kernel underlying most server, container and cloud infrastructure; distinct from the distributions built around it.

  Read Full Context
  and/or Windows.
• Two reachable lab endpoints (a “client” and a “target”) that you are authorised to test against.

#Content

#

The TCP/IP Model and Why Layers Matter

TCP/IP is not one protocol but a stack of independent, cooperating layers, each with its own job and its own failure modes. The Internet Protocol (IP) layer is responsible for addressing and routing: it decides which network a packet belongs to and how it should be forwarded toward its destination, but it makes no promise that the packet will arrive, or that anything is listening when it does. The Transmission Control Protocol (TCP) layer sits above IP and is responsible for establishing a reliable, ordered connection between two specific ports on two specific hosts. Above that again sits the application — the actual service, such as a web server, database listener or replication agent — which may accept, reject or simply not exist on the port you expect. The RFC Series, maintained by the RFC Editor, documents the technical specifications that define this layering and the behaviour each layer is expected to exhibit; it is worth treating as the reference point when a claim about protocol behaviour needs checking, rather than relying on memory or folklore.

#

The Three-Way Handshake as Evidence

A completed TCP three-way handshake — a SYN from the client, a SYN-ACK from the target, and an ACK back from the client — is the strongest evidence you can gather that a specific service is both reachable and listening on a specific port. Tools such as nc, telnet or PowerShell’s Test-NetConnection attempt exactly this handshake and report whether it completed, was actively refused, or simply timed out. Each of those three outcomes has a different cause: a completed handshake means the path and the service are both working; a refusal means the path works but nothing is listening on that port; a timeout is ambiguous and usually means a firewall or ACL is silently dropping the traffic rather than rejecting it. Internet Control Message Protocol (ICMP) echo requests — what ping actually sends — test something different again: basic reachability at the network layer, with no reference to any particular port or service at all. Treating a ping result as proof of application-level reachability is one of the most common reasoning errors in this kind of validation work.

#

Trust Boundaries, Firewalls and NAT

Enterprise networks are rarely a single flat segment. Traffic between a client and a target service typically crosses several administrative and security boundaries — subnet boundaries, firewalls, network address translation (NAT) devices and access control lists (ACLs) — and each boundary can apply different rules to ICMP than it applies to a specific TCP port. This is precisely why least-privilege access matters here as much as it does for any other operational task: the account you use to run diagnostic commands should have no more network reach than is strictly necessary for the validation, and any change to a firewall or ACL rule to support testing is itself a state-changing action that needs its own authorisation, evidence and rollback plan. Assuming that a route is safe because a diagnostic tool reports success, without knowing which boundaries the traffic actually crossed, leaves a residual risk that a later configuration change elsewhere quietly breaks the same path without anyone reviewing it against the boundary that changed.

#Examples

#

Worked Example: Validating Reachability to a Named Service

Consider a bounded lab task: confirming that a client host can reach a target service listening on TCP port 8443 in an isolated lab segment. The following sequence separates network-layer and transport-layer evidence deliberately.

1ping -c 4 lab-target.internal

Interpretation: four replies with consistent round-trip times confirm basic IP-layer reachability only. It says nothing about port 8443.

1traceroute lab-target.internal

Interpretation: a complete hop list ending at the target’s address confirms the routing path used, which matters if a later firewall change affects only one of those hops.

1nc -zv lab-target.internal 8443

Interpretation: a “succeeded” message confirms the TCP handshake completed on that exact port — the strongest evidence available that the target application is both up and reachable from this client. “Connection refused” would mean the path works but nothing is listening; a timeout would point to a firewall or ACL silently dropping the attempt, which is where the trust-boundary reasoning above becomes directly useful.

#Exercises

#

Exercise: Bounded TCP/IP Path Validation in an Isolated Lab

Objective: Prove, with recorded evidence, whether a specific TCP service is reachable from a specific client across your lab segment.

Setup: Two lab hosts you are authorised to use — a client and a target — with a known service and port running on the target, and confirmed permissions to run diagnostic commands on both.

Steps: Run the ping, traceroute and nc/Test-NetConnection sequence shown above from the client toward the target, recording the exact command and full output for each.

Expected evidence: Three saved outputs — ICMP result, hop path, and handshake result — for the same client–target pair.

Pass condition: The TCP handshake test reports success on the intended port, and no earlier evidence contradicts it, for example a traceroute that terminates before reaching the target.

Stop condition: If you lack explicit authorisation for the target segment, or traceroute shows the path crossing a boundary you do not recognise or control, stop and escalate rather than continuing to test.

Cleanup condition: Close any open test sessions; if a temporary firewall exception or route was added purely to support the exercise, remove it and re-run the baseline ping/handshake sequence to confirm the environment has returned to its original state.

#Validation Guidance

Read the three results together, not in isolation. A passing handshake with a clean traceroute is unambiguous positive evidence. A failing handshake with a successful ping means the path works but the specific service or port does not — check the service status and any port-specific firewall rule before assuming a network fault. A failing ping with a successful handshake is unusual but not impossible where ICMP is filtered independently of TCP; treat it as a pass for the workflow’s actual dependency, the TCP connection, while noting the ICMP filtering for anyone relying on ping-based monitoring later. Whatever the outcome, keep the literal command and output as your evidence record — a verbal summary of “it worked” is not sufficient for a task that someone else may need to re-verify or rely on.

#Common Mistakes

• Treating a successful ping as proof that the target application, not just the target host, is reachable.
• Assuming “connection refused” and “connection timed out” indicate the same underlying fault, when they usually point to different causes and different owners.
• Running validation commands against a production host or segment without confirmed authorisation, a defined rollback path, and evidence of both.
• Overlooking DNS resolution as an earlier, separate dependency — a workflow can fail before any TCP attempt is made if the name resolves to the wrong address.
• Discarding the exact command and output used during testing, which makes the result impossible to hand over, audit, or re-verify later.

#Production Bridge

Everything above is deliberately read-only and safe to repeat in a lab. Moving the same pattern toward production changes what is at stake, not the reasoning. You will need explicit authorisation for the specific hosts, ports and segments you intend to test, and any firewall, routing or NAT change required to support a real workflow, as opposed to a diagnostic check, is a state-changing action in its own right requiring its own scope, evidence, stop conditions and rollback plan. Diagnostic accounts should be scoped to least privilege rather than broad network access, and test activity against shared infrastructure should be logged so that anyone reviewing the segment later can distinguish your validation traffic from genuine faults. If a boundary you do not administer is implicated in a failure — a firewall you cannot change, a route owned by another team — escalate to the team that owns that boundary with your recorded evidence rather than attempting a workaround.

#Key Takeaways

• ICMP (ping) and TCP (handshake) evidence answer different questions; neither substitutes for the other.
• A completed three-way handshake on the intended port is the strongest available evidence that a specific service is reachable.
• Trust boundaries such as firewalls, ACLs and NAT can treat ICMP and specific TCP ports differently, so route knowledge from traceroute matters when interpreting results.
• Every validation exercise needs an explicit stop condition and a cleanup step, not just a pass condition.
• Escalate to the team that owns a boundary you cannot change, rather than working around it.

Before treating this task as complete, confirm that each validation step produced the exact evidence described above, that any temporary lab change has been rolled back to its original baseline, and that you have escalated rather than guessed wherever a boundary outside your authority was implicated — only then is it reasonable to extend this same bounded pattern to a genuinely production-scoped change under approved permissions.