Use a Kioptrix lab to connect five different observations: an interface has an address, the kernel selects a route, a local neighbor has a link-layer address, a port responds, and an application returns a message. These are related facts, but none substitutes for all the others.
This page teaches observation, not hypervisor configuration. First establish the intended boundary with the network setup guide. Replace every uppercase placeholder below with verified lab values. The documentation addresses in examples are illustrative, not targets to scan.
1. Find the interface and read its prefix
ip -br addr
Identify Kali’s lab interface by comparing it with the VM adapter configuration. Record its name, state and address/prefix. A machine can have several interfaces and addresses; the first address printed is not automatically the lab address.
For an IPv4 example, 192.0.2.10/24 places the first 24 bits in the network prefix. The corresponding network is 192.0.2.0/24. Under that prefix, 192.0.2.20 is in the same IP subnet. With /25, addresses 192.0.2.10 and 192.0.2.130 are in different subnets. Comparing only the first three numbers is not a general subnetting method.
The 192.0.2.0/24 block is reserved for documentation by RFC 5737. It is used here to explain addressing, not to specify your lab’s configuration.
Save: the actual interface, address/prefix and adapter identity. Do not conclude: that matching prefixes prove a common virtual switch, correct routing or isolation.
2. Ask which route the kernel would select
ip route ip route get TARGET_IP
ip route lists routes. ip route get resolves a route for the supplied destination. Look for dev (interface), src (selected source address) and, when present, via (next hop). The ip-route manual explains the distinction; this lookup does not itself test the remote service.
Illustrative output shape, not a captured result:
192.0.2.20 dev eth1 src 192.0.2.10
Here the displayed route uses eth1 and source 192.0.2.10 without a displayed gateway. Your real interface name and output may differ. If the selected path uses a VPN or an unexpected adapter, resolve that mismatch before sending active lab probes.
Save: the selected path and whether it matches the intended boundary. Do not conclude: that a route lookup proves the destination is online or that return traffic can reach you.
3. Distinguish the local neighbor from a remote host
ip neigh show dev LAB_IF
Replace LAB_IF with the verified lab interface. The neighbor table binds network-layer addresses to link-layer addresses on a local link. For IPv4, this includes ARP information. A cached entry is not a fresh application test.
For an on-link target, an entry may help compare the address and MAC with the VM configuration. For a routed destination, the link-layer neighbor is normally the next-hop router rather than the remote machine. Do not label a gateway’s MAC as the target’s identity.
An empty table can simply mean no relevant neighbor entry has been learned. A stale entry is not proof that a device is absent; it is a neighbor-cache state. Preserve the state as shown and interpret it in context. See the ip-neighbour manual.
Save: address, MAC, interface, state and how you matched the identity. Do not conclude: that all neighbor entries are Kioptrix targets.
4. Separate host discovery from a selected TCP check
A ping response, a discovery result and an open port answer different questions. If the target identity and path are established, compare a discovery observation with selected ports:
mkdir -p evidence nmap -sn -n --reason -oA evidence/N001-discovery TARGET_IP nmap -sT -n -p PORTS --reason -oA evidence/N002-selected-tcp TARGET_IP
Replace PORTS with a justified comma-separated port list. Use new filenames for a new run. These examples do not request UDP scanning, service version detection or scripts.
If discovery skips the host, the normal TCP scan may not run. Do not interpret the missing port result as “all ports closed.” Use the -Pn/-sn comparison to investigate the discovery gate on a confirmed target.
Save: literal states, reasons, coverage and completion status. Do not conclude: that an open port proves a product version or vulnerability.
5. Ask the application a protocol-specific question
For an observed HTTP listener, compare the browser with a bounded header request:
curl -I --connect-timeout 5 --max-time 15 http://TARGET_IP:HTTP_PORT/
-I uses HTTP HEAD. A server may handle it differently from a browser GET, so compare methods when the result is surprising. Record the requested scheme, address, port and path, the status and any redirect. A 404 response still demonstrates an HTTP response; it is not the same as a failed TCP connection.
If an observed lab application depends on a hostname, a direct-IP request can select different content. For a hostname you have verified belongs to this lab, a per-command mapping can help compare that behavior:
curl -I --connect-timeout 5 --max-time 15 --resolve LAB_HOSTNAME:HTTP_PORT:TARGET_IP http://LAB_HOSTNAME:HTTP_PORT/
This maps a specific host/port pair for curl without editing the system hosts file. Check whether a proxy changes the connection path. The curl manual documents these options. HTTPS adds certificate and TLS-name considerations; record certificate errors instead of silently bypassing verification.
Save: the actual response and comparison conditions. Do not conclude: that one successful path proves every page works or every hostname resolves normally.
Copy this network observation worksheet
VM and source identity: Lab adapter mode and exact network name: Interface and address/prefix: Expected target identity and current address: Route lookup: device, source and next hop: Neighbor observation and its limits: Discovery result and method: Selected port test, coverage and completion: Application request, response and evidence ID: What is directly established: Earliest unresolved stage: One next check:
When something fails, return to the earliest stage you have not established. A hostname error is different from a connection timeout; a protocol error is different from access denied. Keep the exact message rather than summarizing every problem as “the network is down.”
Store the worksheet in your session notes. Once the path and service response are understood, continue with service enumeration or use the learning roadmap to choose the next foundation task.