NETOps / Defensive Diagnostics

Security & Troubleshooting.

A field guide for isolating ordinary network, server and web failures without guessing. Work from name resolution through routing, TCP, TLS and HTTP, then inspect the host and firewall where the evidence points.

Scope: defensive diagnostics on systems and networks you administer or are authorized to troubleshoot. Packet capture examples are intentionally narrow and diagnostic.
DNS

Does the name resolve correctly?

Start here when a hostname is involved.

dig example.com A +short
dig example.com AAAA +short
dig example.com +trace
resolvectl query example.com
getent hosts example.com

Compare the returned address with the endpoint you actually expect. A successful DNS lookup only proves name resolution, not service reachability.

TCP / PORTS

Is anything listening?

Separate local service state from remote reachability.

ss -lntp
ss -lunp
nc -vz host 443
curl -v --connect-timeout 5 https://example.com/

Refused often means the destination responded but nothing accepted that port. Timeout more often points toward routing, filtering, or an unresponsive host.

TLS / CERTIFICATES

Inspect the handshake.

Certificate, SNI and chain diagnostics.

openssl s_client -connect example.com:443 -servername example.com </dev/null
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates
curl -Iv https://example.com/

Always send the expected hostname with -servername when testing virtual hosts; otherwise you may inspect the wrong certificate.

HTTP

What did the application return?

Reachability is not the same as application health.

curl -I https://example.com/
curl -Lsv -o /dev/null https://example.com/
curl -sS -o /dev/null -w 'DNS:%{time_namelookup} TCP:%{time_connect} TLS:%{time_appconnect} TTFB:%{time_starttransfer} TOTAL:%{time_total}\n' https://example.com/

Timing separates slow DNS, connection establishment, TLS negotiation and server response.

PACKET CAPTURE

Observe the specific conversation.

Use tight filters and short captures.

sudo tcpdump -ni any host 192.0.2.10
sudo tcpdump -ni any port 53
sudo tcpdump -ni any 'tcp port 443 and host 192.0.2.10'
sudo tcpdump -ni any -c 50 -w diagnostic.pcap host 192.0.2.10

Capture only traffic relevant to the issue and handle packet captures as potentially sensitive operational data.

HOST FIREWALL

Inspect before changing.

Determine what policy exists first.

sudo nft list ruleset
sudo ufw status verbose
sudo iptables -L -n -v

Do not disable a firewall as a first troubleshooting step. Confirm the service is listening, identify the path, then inspect the relevant rule or policy.

DECISION TREE

Website is down.

Walk the stack in order.

Resolve the hostname. Is the address expected?
Confirm a route exists to the destination.
Test TCP 443/80. Refused or timeout?
Inspect the TLS handshake and certificate if HTTPS.
Request the URL with curl -v and note status/redirects.
On the server, confirm the service is listening and healthy.
Read service/application logs before changing configuration.
Inspect firewall/proxy/load-balancer policy where evidence points.
DECISION TREE

A port is unreachable.

Find which boundary drops the connection.

On the destination, verify the process is listening on the expected address and port.
Test the service locally on the destination.
Check the destination's route back to the client network.
Test from a nearby host to reduce the path.
Inspect host firewall policy.
Inspect intervening firewall/NAT/security-group policy if applicable.
Use a narrow packet capture to see whether SYN packets arrive and whether replies leave.
DECISION TREE

DNS is wrong or intermittent.

Resolver vs authoritative data.

Query the normal system resolver and record the answer.
Query the expected record type explicitly: A, AAAA, CNAME, MX, etc.
Compare answers from another trusted resolver if appropriate.
Use dig +trace to inspect delegation toward authoritative servers.
Check TTLs and whether an old answer may still be cached.
Confirm the authoritative record itself is correct before flushing local caches.
DECISION TREE

TLS certificate problem.

Expiry, hostname and trust chain.

Confirm system date/time is sane.
Connect with SNI using openssl s_client.
Inspect subject/SAN hostname coverage and validity dates.
Inspect issuer and presented certificate chain.
Compare direct-origin behavior with proxy/CDN/load-balancer behavior if one exists.
Check renewal/deployment logs rather than immediately replacing certificates manually.
ROUTING / PATH

Where will Linux send it?

Local routing evidence.

ip route get 1.1.1.1
ip -br address
ip route
tracepath example.com

The return path matters too. A valid outbound route does not guarantee replies can get back through asymmetric routing or policy.

PROCESS OWNERSHIP

Who owns this port?

Map network symptoms back to a process.

sudo ss -lntp
sudo lsof -iTCP:443 -sTCP:LISTEN -nP
sudo fuser -v 443/tcp