Introduction
Before using a scanner, you need to distinguish an address, a name, a network path, and a service port. These are different observations, and success at one layer does not prove success at another.
This lab supplies a local DNS server and web service inside your Kali environment. You will inspect the network, resolve the training name, and check its TCP listener without scanning a gateway or depending on public targets.
Inspect Addresses, Routes, and Loopback Reachability
In this step, you will inspect the Kali container's network and test a limited local connection path.
Enter the prepared shell and choose the workspace:
kali
cd /home/labex/project
An IP address identifies a network endpoint. An interface is the system's connection to a network; a route describes where traffic for an address should go. Containers have their own network view, so inspect this environment rather than assuming the host's settings.
ip inspects Linux networking. The -brief option requests a compact view of interface addresses:
ip -brief address
Look for lo, the loopback interface, and 127.0.0.1. Loopback traffic stays in this network environment. Other interfaces and addresses may vary. A prefix such as /8 or /16 describes the address's network range; it is not a service port.
Inspect routes:
ip route
A default entry, if present, is used when no more specific route matches. You do not need to scan the gateway or change any route.
ping sends reachability probes. -c 3 limits the test to three probes so it finishes automatically:
ping -c 3 127.0.0.1
You should receive replies and a final packet summary. Exact timing varies. A ping reply shows that these probes received responses; it does not establish that a particular TCP service is listening.
Save your interface observation using the output redirection you already know:
ip -brief address > interfaces.txt
cat interfaces.txt
The saved view should include the loopback interface and its address.
Resolve a Name with the Training DNS Server
In this step, you will distinguish name resolution from service connectivity using a local DNS server.
DNS translates names into records. An A record holds an IPv4 address. This lab supplies a DNS server at 127.0.0.1 on port 5353 and a local name training-web.test; no public DNS service is needed.
dig queries DNS. @127.0.0.1 chooses the server, -p 5353 chooses its non-default DNS port, the next argument is the name, and A requests an IPv4 address record:
dig @127.0.0.1 -p 5353 training-web.test A
The answer section should show the name and address 127.0.0.1. DNS uses ports too: port 5353 here belongs to the training DNS server, not to the web service named by its answer.
The +short display option prints just the answer data. Save that smaller result:
dig @127.0.0.1 -p 5353 +short training-web.test A > dns-answer.txt
cat dns-answer.txt
Expected output:
127.0.0.1
A system name lookup may also use local files instead of querying DNS directly. getent hosts asks the system's configured hosts lookup for a name:
getent hosts localhost
The output associates localhost with a loopback address, which may be IPv6 ::1. This differs from explicitly querying the supplied DNS server with dig. Successful name resolution gives an address; you still need to examine whether the required service is available there.
Inspect a Listener and Test Its TCP Port
In this step, you will connect an address to a particular transport protocol and service port.
A port identifies a transport endpoint at an address. TCP establishes connections; UDP sends datagrams without the same connection handshake. A service's port number alone does not prove what application or vulnerability is present.
ss displays socket information. -l selects listening sockets, -t selects TCP, and -n keeps numeric addresses and port numbers:
ss -ltn
Find the local endpoint 127.0.0.1:8080. It belongs to the supplied training web service. The address restricts it to loopback in the container. Inspect UDP sockets separately with -u instead of -t:
ss -lun
The training DNS endpoint uses port 5353. TCP and UDP have separate port spaces; the same number can be used by both protocols.
Save just the TCP listener row for the practice service. The pattern includes the colon before the port and a trailing space to distinguish it from a longer number:
ss -ltn | grep ':8080 ' > service-listener.txt
cat service-listener.txt
The row should identify LISTEN and 127.0.0.1:8080; spacing and queue values can vary.
Ncat can test a TCP connection without sending application data. -v prints status, and -z requests a connection check rather than an interactive data session:
ncat -vz 127.0.0.1 8080
The status should report a successful connection. This proves that the selected TCP port accepts a connection now; it does not yet validate an HTTP response. You will inspect HTTP itself in a later lab.
Summary
You inspected interfaces and routes, sent a finite reachability test, queried local DNS, inspected TCP and UDP listeners, and tested one TCP connection. You distinguished successful resolution and network reachability from application-level behavior.
