03 / TCP, UDP, service ports and DNS

One address can host several services

Prerequisites: lessons 1–2. TCP provides an ordered byte stream using connection state, acknowledgements and retransmission; it cannot promise the application will succeed. UDP sends datagrams without built-in delivery or ordering guarantees. A socket endpoint combines an IP address, transport and port. A client usually uses a temporary ephemeral port; the server listens on a configured service port.

Worked example: illustrative client 10.77.10.10:49152 → server 10.77.20.10:8080 over TCP. Actual client ports vary. Reply: 10.77.20.10:8080 → 10.77.10.10:49152. Port 8080 is chosen for this helper; it does not prove application identity. DNS resolves names into records such as addresses, commonly using UDP or TCP 53. A name-based application may need both DNS access and application access. This lab has no DNS server.

Keep these terms beside the explorer

Socket endpoint

An IP address, transport protocol and port used by a communicating application. TCP 8080 and UDP 8080 are different transport endpoints.

Ephemeral port

A temporary client port chosen by the local stack. The illustrated 49152 is an example, not a runtime requirement.

Listener

A process waiting for traffic on a local address/transport/port. ss -ltn reads numeric listening TCP sockets.

SYN / ACK

TCP flags used in connection setup and acknowledgement. The three-message handshake is SYN, SYN-ACK, then ACK.

DNS A record

A DNS record supplying an IPv4 address for a name. An answer alone does not prove application access.

HTTP status

An application response code such as 200 or 404. Receiving an HTTP error is different from failing to establish any useful response.

Build the idea: transport setup, application data and naming

The address chooses an interface destination; the transport protocol and port choose a communication endpoint there. TCP port 8080 and UDP port 8080 are different transport endpoints. A server process must bind/listen on the address and transport expected by the client. A temporary client port lets the stack distinguish conversations; 49152 in these examples is a teaching value, not a promised runtime port.

Read the TCP handshake as three messages: SYN starts connection setup; SYN-ACK answers that setup from the server; ACK acknowledges it from the client. Afterward, HTTP request bytes can travel inside TCP. TCP supplies an ordered byte stream, so an HTTP message may span several segments or share a segment with other bytes; the illustrations do not assert packet-for-message boundaries.

What DNS adds—and what this lab deliberately supplies locally

A name such as app.qcs.test needs an address selection mechanism before the application can connect. A DNS A record can supply an IPv4 address. DNS is a separate conversation, commonly using UDP or TCP destination 53. A successful lookup does not permit the later HTTP flow. Conversely, an HTTP request to a numeric address does not require a lookup for that address.

The resolver in the explorer is an abstract dependency, with no assigned address, cable or configured GNS3 node. The actual exercise uses a numeric URL and then curl --resolve. The latter supplies a name/address mapping for that one curl invocation; it does not alter the system resolver or send a live query for that supplied mapping. Keep that distinction in the evidence worksheet.

HTTP status is another layer of evidence

HTTP 200 means the server answered the request successfully at the application layer. HTTP 404 from the included helper means it answered but did not serve that requested path. A connection refusal, timeout and HTTP error are different observations. None should automatically be renamed “FortiGate blocked it.” Plain HTTP does not encrypt the request or response.

Lab 03: prove each dependency separately

Conditional practical: complete the exact-build setup and baseline gates first. Until then, use this as guided analysis and leave observed results blank.

1. Start the helper in its foreground server console. In a supported second server terminal, run ss -ltn. If a second terminal is unavailable, stop for the instructor’s console method; do not improvise process control.
2. Read the listening address and port. Expected: 10.77.20.10:8080. A listener on a different address, including loopback only, does not match this baseline.
3. From the client, request the numeric URL. Record status and fixed body if received.
4. Use the correct --resolve mapping. Record whether the same helper responds. State explicitly that no resolver was tested.
5. Only after verifying .99 is unused in the isolated project, run the wrong-mapping command once. Keep the timeout bounds; do not broaden the policy.
6. Restore the command mapping to .10 and retest. No hosts/resolver file was modified. Stop the helper with Ctrl+C after the final successful comparison.

SERVER second Ubuntu terminal:
ss -ltn

CLIENT numeric request:
curl --noproxy "*" --connect-timeout 3 --max-time 5 --include http://10.77.20.10:8080/

CLIENT correct mapping:
curl --noproxy "*" --connect-timeout 3 --max-time 5 --include --resolve app.qcs.test:8080:10.77.20.10 http://app.qcs.test:8080/

CLIENT bounded wrong-mapping fault; only if .99 is verified unused:
curl --noproxy "*" --connect-timeout 3 --max-time 5 --include --resolve app.qcs.test:8080:10.77.20.99 http://app.qcs.test:8080/

Diagnosis order: listener first, numeric HTTP second, mapping string third. If numeric HTTP already fails, changing DNS is not a supported fix. The wrong .99 address also does not match the baseline’s server /32 permit; its failure cannot isolate DNS from policy. Acceptance: listener matches, numeric and correct-mapping requests return the expected response, the original mapping is restored, and cleanup is scoped to the helper.

See the conversation

Detailed diagram: scroll horizontally to inspect full-size labels. The text path below reflows on phones.

Slow packet film: 14 steps, six seconds per step (84 seconds total). Pause to inspect the headers, or use the explorer above at 10/15 seconds per step. Film timing is instructional; it is not measured network latency.

No autoplay. Use native pause or leave the static diagram visible. Reusable GIF download. The static diagram and caption are the reduced-motion alternative; GIFs are not embedded.

Practical 03 • separate listener, HTTP and naming

Conditional practical: complete the exact-build setup and baseline gates first. Until then, use this as guided analysis and leave observed results blank.

Start the helper in the server console. In a second server terminal inspect the listening socket. If GNS3 exposes only one console, use a supported second guest terminal or stop and ask the instructor; do not background unknown processes.

SERVER second Ubuntu terminal:
ss -ltn

CLIENT:
curl --noproxy "*" --connect-timeout 3 --max-time 5 --include http://10.77.20.10:8080/
curl --noproxy "*" --connect-timeout 3 --max-time 5 --include --resolve app.qcs.test:8080:10.77.20.10 http://app.qcs.test:8080/

ss inspects sockets; -l means listeners, -t TCP, -n numeric values. Expected listener: 10.77.20.10:8080. This command is read-only. --resolve supplies an in-command name/address mapping for curl only; it is not a DNS query and changes no hosts file.

1. Record the listener and numeric HTTP result; expect 200 if baseline passes.
2. Run the supplied mapping request. Expected same HTTP response; it isolates name selection without a DNS server.
3. Bounded fault: change only the mapping in the command to app.qcs.test:8080:10.77.20.99, after verifying .99 is unused in this isolated project. Expect failure. This is a deliberately wrong local mapping, not proof of DNS filtering.
4. Rollback: rerun the original mapping to .10. No persistent file was changed. Acceptance: correct listener and HTTP 200 return. Cleanup: Ctrl+C in helper terminal.

Diagnosis and practice

Check three things in order: listener address/port, literal-IP HTTP result, supplied mapping string. If numeric access fails, do not start changing DNS. Stop after these checks and restore the original command. UDP and real DNS remain guided-analysis activities: draw client → resolver:53 and then client → application:8080 as two separate conversations. Practice: reverse the worked tuple; explain why a successful --resolve request does not prove DNS works; name one reason an allowed port may still fail. Answers: server:8080 → client:49152; no resolver was queried; stopped listener or missing route.

Evidence and boundaries

Use the evidence worksheet. Write prediction before observation; record time, exact command, endpoints, policy ID if available and a redacted result. Leave actual-result cells blank until tested. Never paste passwords, license files, serials, full configurations or recovery backups into the preview.

Stop after one failed attempt and up to three focused checks. A timeout alone is inconclusive: service, route, host filtering or firewall policy may be responsible. Restore the stated fault before trying a different hypothesis.

More practice • explain before revealing the answer