Learn › Linux networking › Independent diagnosis
A real three-machine networking investigation with chapter-specific checks.
Client cannot open the health page using app.lab.test. Find the cause or causes, explain the smallest permitted change and show that the required restriction still works. The launch control offers a first incident and a changed incident. Each starts fresh machines after the prior session has ended. Read the current case name and descriptor before testing.
Complete Chapters 1 through 7 first. This chapter brings together addresses and routes, DNS, listening services and firewall decisions. It uses the tools you have already practised. You choose which tests to run and in what order.
A name, an address and a listening service are different parts of a request. DNS supplies an address for a name. Client then tries to open a TCP connection to a port at that address. Routing and firewall rules affect whether the traffic reaches Server and returns. A listener is a program waiting for connections on a particular local address and port. Once connected, HTTP requests a resource such as /health.txt.
For example, a correct DNS answer can lead to a failed HTTP request if the requested port differs from the service's listening port. A process that listens on a loopback address accepts requests made on its own machine, but not traffic sent to a different address on that machine. A service can also remain bound to an old address until its configuration is applied by a restart. Conversely, a healthy service at the assigned address cannot correct a wrong DNS answer. These examples explain mechanisms; they are not evidence about either current incident.
Use the named Client, Router and Server terminals. Confirm the terminal name and prompt before each command. Selecting a node on Topology does not redirect a command already entered in another terminal.
10.71.10.10 on eth1.10.71.10.1 on eth1 to 10.71.20.1 on eth2.10.71.20.20 on eth1.The required A record, which maps a name to an IPv4 address, is app.lab.test to 10.71.20.20. Client must receive that answer from Router DNS over both UDP and TCP. These are two ways to query DNS on port 53; neither query tests the web service on port 8080.
Your repair must satisfy all of these requirements:
http://app.lab.test:8080/health.txt. Its body is linux-camp-networking-ok followed by one newline.10.71.20.20:8081/health.txt succeeds. This proves the blocked Client request is not simply caused by a stopped service.Read /etc/lab/topology.json and /etc/lab/chapter.json. The internal chapterId is 10 even though this is displayed Chapter 8. The descriptor includes the opaque case selected at launch. In the first incident, the only permitted repair objects are Router's additional-hosts file inside dnsDir, its dnsUnit, and an individual rule in its table. In the changed incident, the only permitted repair is Server's owned listenerDir/bind file and a restart of listenerUnit; Router policy is available to inspect but not change. The resolver file is separate from /etc/hosts. The exact session names change at launch.
labnet is the lab's restricted helper, not a standard Linux command. It checks the current node and session-owned object before running a real Linux operation. Use its permitted syntax and the descriptor's current names. Do not guess a rule handle or reuse one from another session. A handle is the number nftables assigns to a live rule.
Leave the platform's management connection on eth0 unchanged, including its SSH configuration and default routes. This connection keeps your browser terminals available; it is separate from the exercise traffic on eth1 and Router's eth2.
Also preserve /etc/hosts, /etc/resolv.conf, exercise addresses/routes, forwarding, application code/body, unrelated firewall rules, the TCP/8081 restriction and any service not named in your case's repair boundary. Do not stop the firewall, flush tables or redirect the application through another port. If your evidence requires a change outside the boundary, report a problem with the prepared lab and include the output that led you there.
This incident checks the running session. It does not test reboot persistence. Resetting or ending the lab does not preserve your repairs. Save your evidence first.
As a neutral worked example, imagine a test program configured for 192.0.2.7 that still uses its earlier bind until restart. Inspect the running socket and the configuration separately. If the evidence warrants a change, edit only its owned setting, restart that one service and inspect the socket again. Those documentation addresses are not values accepted by this lab.
Write down at least two plausible explanations for the failed operation. For your leading explanation, predict one result that would support it and one that would make you reconsider. Choose a test that distinguishes the explanations without changing the system.
For each observation, save the terminal, exact command, time, output and exit status. A nonzero status tells you the command did not complete successfully; the output helps explain why. Read a DNS response's status and answer too. A successfully executed DNS query can report that the requested name does not exist.
Keep four short notes for each test:
1. Explanation: what you think might be wrong. 2. Prediction: the result that would distinguish it from another explanation. 3. Evidence: the original output you actually observed. 4. Decision: whether the result supports, refutes or leaves your explanation uncertain.
Try to disprove your leading explanation at least once. You may consult the reference later in this lesson if you forget syntax.
Inspect the running system.
Choose your observations and explain what each one tells you. Comparing a request to the assigned Server address with a request using the observed DNS answer can separate name resolution from service reachability. A local Server request and a listener listing answer different questions from a Client request.
If you use an owned firewall counter, record it before and after one bounded Client request. A counter counts matching packets, not successful web transactions. More packets may appear because TCP retries. Automatic workspace checks also send traffic, so a counter increase cannot identify your request alone. Use it alongside the request result and rule matches, and state that limit in your notes. Read rule order as well as counters.
A successful ping does not prove that TCP/8080 is allowed. A listener does not prove Client can reach it. A per-request address override does not prove DNS is correct. One failed request or one empty capture does not locate a fault by itself.
Use actual DNS responses, HTTP results, listener information and the owned policy counters for this incident. Each observation answers a different question about the failed request.
Before changing anything, identify the supporting observations, state the smallest permitted change and predict which result should change. Name a control that must remain unchanged.
For a first-incident DNS record correction, change only the owned record and send HUP to the owned DNS unit using labnet. HUP asks this resolver to reread its additional-hosts records. For a first-incident firewall correction, inspect the live owned chain and use the current handle of the one rule your evidence identifies. The helper does not grant a general root shell.
Repeat the test associated with the repair, then repeat the original named workflow. If one test improves but the workflow still fails, retain both results and investigate the remaining failure. More than one cause can prevent the same operation. If your predicted result does not change, reconsider before making another edit.
There is no required repair order. Your explanation should show why each change followed from the evidence and what remained unresolved after it.
Verify the whole contract.
Use fresh observations to verify the original name-to-application operation and the restrictions that must survive. Check UDP and TCP DNS, an unlisted name, HTTP using the actual answer, direct-address HTTP, Server's local services and listeners, the blocked Client TCP/8081 request with its matching deny counter, and both exercise ping directions. Compare preserved routing and management state with the session baseline.
Read the exact HTTP body as well as the exit status. A successful connection alone does not prove the correct page was returned. A blocked TCP/8081 request is only useful evidence when Server's local control still works.
The workspace checks the session's behavior and preservation requirements automatically. Compare those results with your manual observations. A failed or missing observation needs investigation; do not replace it with expected output.
If checker probes overlap your measurements, explain which conclusions the combined evidence supports and which remain uncertain.
Save a concise report containing the failed operation, each supported cause and its location, a test that distinguished your explanations, one rejected explanation, your exact changes and the fresh verification. If a repair improved one result but left the original workflow failing, explain what remained unresolved. State which traffic or future conditions you did not test. Attach original output. Label any path drawing as a model supported by named observations.
Save a copy outside the disposable lab before ending the session. There is no report-upload control in this workspace. Include each attempt's start and end time, when you returned to the changed case, and any reference, hint or answer used.
What the checks mean: they verify machine state, not your reasoning. A person must review your explanation and assistance record before calling the diagnosis independent. Using an answer makes the attempt assisted practice. An immediate changed-case attempt is practice; returning later can provide retention evidence. A completed reading, a machine pass or a time gap alone does not prove mastery.
This reference provides syntax, not an order of investigation. Use it when you need help with a command.
On Client, dig asks a DNS server directly. Read its status and A answer. Add +tcp to repeat the same question over TCP, or replace the name with absent.lab.test for the unlisted-name control.
dig @10.71.10.1 app.lab.test A +time=2 +tries=1On Client, curl requests the resource directly from the assigned address. The time limits keep a blocked request short. --noproxy '*' keeps a configured proxy out of this experiment; --fail makes an HTTP error response fail the command. Changing 8080 to 8081 tests the control port. On Server, the same commands test its own exercise address locally.
curl --noproxy '*' --fail --connect-timeout 2 --max-time 4 http://10.71.20.20:8080/health.txtTo follow a DNS answer manually, use its one observed A address in --resolve. For example, the following is appropriate only if your actual answer was 10.71.20.20. If it was .21, use that observed address instead and retain the failure. Do not substitute the required address and call it a DNS-following test. Curl receives the supplied mapping here; it does not ask Router DNS itself.
curl --noproxy '*' --fail --connect-timeout 2 --max-time 4 --resolve app.lab.test:8080:10.71.20.20 http://app.lab.test:8080/health.txtOn Server, ss lists listening TCP sockets. Read the local address and port. 127.0.0.1 means loopback, reachable only from Server itself. 10.71.20.20 is Server's exercise address. This interpretation is useful evidence, not permission to change a binding outside the current contract.
ss -H -lnt '( sport = :8080 or sport = :8081 )'On Client, ip -4 route get 10.71.20.20 shows the selected IPv4 route. ping -n -I eth1 -c 3 -W 1 10.71.20.20 sends three bounded probes through the exercise interface. On Server, use Client's 10.71.10.10 as the destination to inspect the return direction.
For Router policy, use labnet nft -a list chain inet TABLE transit, replacing TABLE with the current descriptor value. -a includes handles. Read matches, order, decision and counters together. For a supported repair, labnet nft delete rule inet TABLE transit handle HANDLE removes only the identified current rule. Read labnet help for the exact owned DNS file and HUP syntax. Do not paste these capitalized placeholders into a terminal.
For the changed case, labnet help on Server gives the exact owned bind path and unit name. The bind file accepts only 127.0.0.1 or 10.71.20.20, each followed by a newline. Piping one value through labnet tee changes the configuration file; labnet systemctl restart UNIT.service applies that configuration to the owned HTTP unit. The broker refuses other files, addresses, ports and service actions.
Hints, if you need them: compare the DNS answer with the assigned address; compare a direct request with local service health; then inspect the listener and the current owned policy decision.
After ending the first session, choose Changed incident to launch a separate fresh case. It revisits Chapter 4's name-and-listener problem. The same service requirements and preservation checks apply. Do not carry a repair from the first incident into this session; select tests from the new evidence.
Begin with its service contract and permitted objects. Select your own observations before opening this reference or your earlier report. The symptom may resemble the first incident, but repeating its repairs is not a diagnosis. Predict, inspect, justify a change and verify the complete contract again. Save fresh output and an explanation with your attempt record.
Return to this changed problem later if practical, so you can test what you recall without rereading your first report.
Practice Chapter 8. Independent diagnosis in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.