Testing Connectivity with Essential Linux Utilities: An Admin‘s Guide

Do you manage Linux servers? Do websites randomly go offline? Do apps lose connections to databases? Do remote servers disappear without warning?

Content Navigation show

We‘ve all been there. Network issues can cause no end of headaches!

The first step in any diagnosis is confirming if basic connectivity exists between endpoints. Getting a handle on this right away saves you countless hours troubleshooting application code or hunting down server failures.

In this guide, I‘ll equip you with 6 must-know Linux utilities guaranteed to help track down connectivity problems faster.

We‘ll cover:

telnet – Test manually connecting to TCP services
nc – Swiss army knife TCP/IP networking tool
wget – Check connecting to web servers
curl – Multi-purpose connection testing
nmap – Port scanning and service discovery
ping/ping6 – Confirm network reachability

I‘m Chandan Kumar, a Linux infrastructure expert and author with years of experience using these tools to diagnose nasty network issues!

So let‘s get started making connectivity troubleshooting way easier for you!

Telnet: Your Direct Line to Any TCP Service

Before we worry about specific applications, websites or hardware, we need to check basic socket connectivity. Can we establish TCP handshakes between endpoints?

That‘s where good ol‘ telnet comes in handy. Telnet allows creating a raw bidirectional flow for sending and receiving data directly over TCP.

Originally created in 1969, it predates even FTP for directly checking connectivity to services using TCP streams.

To use telnet for connectivity checks, specify the target server address and TCP port:

telnet 10.0.0.5 22

This tries connecting directly to 10.0.0.5 on port 22 (SSH).

If the connection succeeds, you‘ll get interactive access to the raw service protocol for sending text. This allows basic communication confirming the port is listening and accepting connections as expected.
If the port refuses connections or a firewall blocks access, telnet will timeout or error immediately. Indicating issues reaching the service.

For example, let‘s demonstrate connecting to SSH on a server:

$ telnet server01 22
Trying server01...
Connected to server01.
Escape character is ‘^]‘.
SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3

Login as: root

The "Connected" message and SSH protocol greeting confirm we‘ve successfully established connectivity to the target system.

While great for quick checks, telnet has some downsides:

Telnet transmits all data (including passwords) in plaintext over the wire
Increasingly disabled on modern Linux distros causing issues finding the client
Limited to checking TCP services only

So while handy, you may want some alternatives…

When to use telnet

Despite some limitations, telnet excels at manual interactively testing connectivity to TCP networking services.

You have an application losing connections to a database on 3306? Try telnet dbhost 3306 to check the basics.

Website failing? Ensure TCP port 80/443 connectivity exists with telnet before diving deeper.

Any scenario where an TCP client can‘t reach a TCP server, telnet helps confirm if basic socket connectivity exists.

nc – Networking Swiss Army Knife

If telnet seems risky or you want to test more than just TCP services, it‘s time to pull out the big guns – nc!

nc (or netcat) is like a versatile Swiss Army knife for connecting to network services. The "TCP/IP swiss army knife", as the original author called it.

First released in 1995, nc implements a simple yet highly customizable TCP, UDP and UNIX socket client and server. All with handy command line flags for scripting tests.

Let‘s see basic nc syntax for connectivity checking:

nc [options] destination_host destination_port

The bare command tries connecting to the given port on the target server. If successful, it returns an interactive session.

We can add the -vz parameters to do a pure connection test without sending/receiving data:

nc -vz 10.0.0.5 22

On success you‘ll see output like:

nc: Connected to 10.0.0.5:22

Nice and clean!

For even more flexibility, consider adding timeout durations, retrying failed tests, and writing custom application layer requests using nc.

I encourage spending time digging into nc‘s man pages – with over 120 flags it can tackle almost any networking scenario!

Below is a handy comparison of some key advantages over telnet:

Feature	telnet	nc
TCP tests	Yes	Yes
UDP tests	No	Yes
Custom app requests	No	Yes
Port scanning	No	Yes
Scriptable	Hard	Easy
Encrypted	No	Using wrappers

So while telnet gets the TCP job done, nc adds many useful extras!

Unleash the power of nc

Any scenario where telnet falls short, it‘s worth reaching for nc instead:

Testing UDP-based services like DNS queries
Need to script automated connectivity testing
Crafting custom application layer data for deeper testing
Binding ports and proxying connections for further diagnosis

Getting familiar with nc arguments transforms it from a simple scanner to an indispensable connectivity toolkit.

wget: Download Websites for Connectivity Checks

So we‘ve covered utilities focused on specific networking protocols. Now what about checking connectivity to web applications and sites?

That‘s where good old wget comes to the rescue!

Released in 1996, wget began life as a handy utility for mirroring websites by…you guessed it – getting content from the world wide web!

But beyond simply downloading websites, wget contains highly customizable options tailored for web connectivity testing as well.

Executing a simple wget against a website will attempt first establishing TCP connections on port 80/443:

wget example.com

On success, wget then issues an HTTP GET request for the index page and starts downloading the response content.

Any network timeouts, DNS failures, TLS handshakes issues or HTTP protocol errors will cause wget to report the failure. Indicating connectivity problems reaching the website.

Consider enriching the connectivity check with some additional flags:

wget -S --spider example.com

-S – print response headers to stdout rather than downloading content
--spider – don‘t download body content after getting headers

This tests connectivity without pulling down full site data – perfect for checks.

For example, testing successful connectivity to a secure site might display:

$ wget -S --spider example.com
Connecting to example.com (93.184.216.34:443)
HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  Date: Thu, 02 Mar 2023 22:11:35 GMT
  ...

Getting headers back confirms your client can reach the website. Any errors indicate breaks in connectivity preventing access.

Here are some key things to consider around using wget:

Pros	Cons
Easy website connectivity testing	Only supports HTTP/HTTPS
Customizable flags for connectivity-focused checks	More than you need for testing one site
Helper tools for parsing output	No built-in port scanning features

So turn to wget when you specifically need to test web application availability from a Linux host.

Wgetting to the bottom of web issues

Nothing hurts worse than an angry call that a website is down!

Before falling down a rabbit hole of application errors, check basic connectivity with wget:

wget -S --spider website_url

No response? Check DNS lookups, then pivot to nc or nmap for ports 80/443 testing next.

Getting headers back? The web server is likely reachable and you can investigate HTTP-level application issues on the server side or client browsers.

Don‘t forget to try both HTTP & HTTPS in case one protocol is misbehaving!

curl: The All-in-One Connectivity Tool

Our last broad connectivity toolkit is the venerable curl client. Released in 1997, curl aimed to provide a single unified command line interface supporting many application protocols:

HTTP/HTTPS
FTP
SMTP/POP3/IMAP
Telnet
LDAP
*…and more!

This Swiss army knife design makes curl perfect for quickly swapping between protocols to test connectivity:

curl protocol://destination_host[:port]

Simply change the protocol prefix and destination port to test anything curl supports:

Web UI not loading? Try curl https://mysite.com
Mail server offline? Check with curl smtp://mail.myco.com
FTP files not transferring? curl ftp://storage:21

On success, curl will print header information from the destination server confirming TCP and application handshakes completed properly.

Any errors indicate connectivity issues or protocol mismatches preventing communication.

Now of course many Linux distributions have native utilities for the above protocols – httpd, ftp, email clients, etc.

So why use curl instead?

Doesn‘t transmit additional data for tests only
Flexible protocol support from single command
Easy to manipulate requests for troubleshooting
Helper libraries to parse, format and validate responses

Curl wraps up all the fundamentals for convenient connectivity verification across common application services.

Curl up with versatility

With support for nearly any application protocol, curl should be your go-to for quickly pivoting connectivity tests:

Web app not loading? Try both curl http:// and curl https:// prefixes
Emails failing to send? Check curl smtp:// responses
Unsure if LDAP integration is working? Info from curl ldap:// will tell you

Getting headers back confirms the service is reachable. Errors indicate network or application faults preventing connectivity.

Curl does it all – complement more protocol specific tools with curl for versatile high level testing.

nmap: Pinpoint Port Access

Thus far we‘ve covered flexible clients for testing connectivity across protocols. But what about discovering services and methodically probing ports?

For that we need something designed for targeted port scanning and network mapping – enter nmap!

First released in 1997, nmap revolutionized discovery and security auditing of networks. Quickly scanning ranges for open ports and fingerprinting services.

The name "nmap" even stands for "Network Mapper"!

While extremely versatile, we‘ll focus on using core nmap functionality for basic connectivity verification:

nmap -p destination_port destination_host

This tests if we can establish TCP connections to the given port on the target server.

For example, probing SSH on a backend system:

nmap -p 22 backend01

Nmap then prints output indicating the discovered state:

Host: backend01 ()    Port: 22/tcp  State: open

An "open" state means nmap successfully connected confirming the port accepts traffic.

Other potential results include:

filtered – Firewall is blocking access
closed – Nothing listening on the target port
no response – Host could be offline or unreachable

This straightforward probing with nmap can decisively check connectivity status on specific ports quickly.

Some additional advantages over other scanners:

Fast parallel scanning of multiple hosts
Output formats from simple to detailed
Advanced host discovery and OS fingerprinting
Custom network packets for penetration testing
Scripting engine for automating checks
Granular output control for connectivity focus

Nmap has far more features we can‘t cover fully here! But even just basic TCP port scanning proves invaluable.

Map your connectivity strategy

firewall got you locked down?

nmap -p 80,443 1.2.3.0/24

Find open web ports to identify accessible servers.

Databases refusing connections?

nmap -p 3306 dbhost

Verify if MySQL port allows traffic before debugging queries.

Full stack not working?

Scan all application related ports on involved hosts to check connectivity at each layer, then work bottom up!

Nmap fits neatly into any methodology needing port level visibility for connectivity troubleshooting.

Ping & Ping6: Test Basic Reachability

Last but not least, we arrive at the venerable ping!

Introduced all the way back in 1983, ping began life as command simply sending ICMP echo requests to check basic reachability.

Over 35 years later, ping remains a staple in every networking toolkit for the first basic connectivity check – is the remote host even awake?

ping continues this legacy by sending ICMPv4 or ICMPv6 echo requests to check if a target IP host responds:

ping destination_host_or_ip

Replies indicate a basic level of connectivity and availability. Whereas request timeouts or destination unreachable errors show serious network issues exist dropping traffic.

There is also a separate ping6 variant specifically for testing IPv6 connectivity:

ping6 ipv6_address_or_hostname

The same principles apply – responses mean IPs are routable, errors show problems.

Some key ping considerations:

Quick first check before TCP/UDP service tests
Subject to false negatives if ICMP blocked
Requires hostname resolution if not using IPs
IPv4 vs IPv6 network issues may differ

So treat no ping replies as hints of unreachability, not conclusive proof. Follow up with nmap scans for deeper investigation.

Pinging the first domino

About to spend way too long troubleshooting why that database server can‘t be reached?

Start simple:

ping db01

No response? Check DNS, then ping the IP address instead to test layers.

Ping timing out? Verify local network hardware, switches and firewalls aren‘t dropping traffic.

Getting replies back? Database running on unusual port? Quick nmap scan will check.

Basically any network connectivity scenario begins with simple ping checks as a fast first step. From there explore further guided by responses vs errors!

Let‘s Recap: Connectivity Testing Best Practices

After all that, here is a handy table summarizing the Linux connectivity tools we covered for your next outage:

Utility	Key Features	When To Use
telnet	Manually interact with TCP services	Verify connectivity to known TCP ports
nc	Custom TCP/UDP connectivity client	Anything complex or non-TCP
wget	Test HTTP/HTTPS web connectivity	Websites failing to load
curl	Flexible cross-protocol connectivity client	Rapidly pivot between app protocols
nmap	Port scanning and service identification	Find open ports or fingerprint apps
ping	ICMP echo checks	First step in any diagnosis

I suggest getting cozy with all 6 tools – each bring unique strengths complementing the others. Memorize this table, bookmark this post, but most importantly practice using them!

The best troubleshooters turn tools into instincts through experience across many battles!

To conclude, let‘s walk through a high-level scenario demonstrating how these utilities can systematically narrow down connectivity issues:

"The app server can‘t reach the database and pages won‘t load!"

ping app + db servers – are they online?
nc attempt connections from app to db on 3306 port – firewall blocking?
nmap scan web ports (80/443) between components- traffic allowed?
curl simulate HTTP requests from app to web tier – back end connectivity okay?
wget check DNS resolution and get index from browsers – clients hitting web heads?

Combine critical thinking with the right tools at each stage and problems become puzzles. Rinse, repeat across many high stress outages to gain sysadmin zen!

Hopefully this introduction to Linux connectivity troubleshooting proves valuable in your infrastructure adventures. Let me know which utilities you find most indispensable!

But for now…happy networking!