Refused: Isolate Why the App Can't Reach the Database
MediumNetworking20-30 minweb01's application can't reach its database on db01, and connections are refused. Work the problem the way a SOC/sysadmin does — layer by layer — using the captured diagnostics in /root/case/: ping.txt (L3), dig.txt (DNS), nc.txt (the TCP connect), and db_ss.txt (ss -tlnp on db01).
Connectivity is fine (ping succeeds) and DNS resolves, yet the TCP connect is refused. That rules out the network and points at the service. The ss LISTEN table has the answer: the database process is up, but bound to 127.0.0.1 — so it accepts only local connections and refuses every remote one. This is the single most common 'service unreachable' cause. The public services (sshd, nginx) are correctly on 0.0.0.0; those are decoys.
Record what your isolation finds:
1. The exact socket the database is wrongly listening on, as address:port the way ss prints it (/root/case/finding.txt).
2. The database port the app needs (/root/case/port.txt).
3. The name of the process bound to loopback (/root/case/service.txt).
The fix, for reference, is to bind the service to 0.0.0.0 (or the LAN address) and restart it — but this lab grades the diagnosis.
- Isolate a connection failure layer by layer (L3 -> DNS -> L4 -> service)
- Read an ss LISTEN table and spot a service bound to loopback
- Record the offending socket, the port, and the process — not the public decoys
- Learn the most common 'service unreachable' root cause: bound to 127.0.0.1
Hands-on lab: you work on a real Linux box in your browser, graded on the machine's actual state.