Validate the source path and discover hosts
Needs: Correct VPN/interface and explicit scope; discovery probes must be compatible with the path
From the target's working folder
Purpose: Confirm the source path and discover explicitly assigned hosts before spending time on port coverage.
# From the target's working folder
mkdir -p scans
ip -br addr
ip route get TARGET
# One host
nmap -sn -n -oA scans/host TARGET
# Host discovery
nmap -sn -n -iL targets.txt -oA scans/hosts
# Explicitly assigned subnet
nmap -sn -n -oA scans/subnet SUBNET
Read: selected interface/source address. A route lookup does not prove reachability.
Verify → Record source address/interface, route and the exact responding endpoint; a missing ping response does not prove a host is down.
If it fails → No route or wrong VPN interface is an environment failure. If only discovery is blocked, use the known-host TCP method; a SOCKS path requires a compatible connect-based client. More detail ↓
Explanation & examples
Validate the source path and discover hosts
- USE WHEN
- No response, a new subnet, or uncertainty about the interface and route
- STARTING ACCESS
- An explicitly assigned address or host list and a known source position
- RESULT
- A source-qualified reachable-host list and a defensible discovery limitation
Recognize the clue
From the assessment host inspect the assigned interface and the route to the exact target before interpreting silence.
ip addr
ip route get TARGET
nmap -sn SUBNET -oA host-discovery
TARGET via VPN_GATEWAY dev tun0 src SOURCE_IP
Nmap scan report for HOSTNAME (TARGET)
Host is upMeans: The route names the intended interface/source; a responder is evidence from that source, not a global reachability claim.
Confirm: Check scope, target state and whether host-discovery probes are permitted by this path.
- After validation
- The assigned route is correct and the selected application responds: proceed to service coverage.
- Ruled out in this context
- The route points outside the assigned VPN: repair that route before evaluating the target.
- Still inconclusive
- No discovery response but a plausible route exists: the host may filter probes; test a justified selected port.
Troubleshooting: No route or wrong VPN interface is an environment failure. If only discovery is blocked, use the known-host TCP method; a SOCKS path requires a compatible connect-based client.
Purpose: Confirm the source path and discover explicitly assigned hosts before spending time on port coverage.
1. Check the path
From the target's working folder:
Read: selected interface/source address. A route lookup does not prove reachability.
Variants — discover one host, a host list or a subnet
Host discovery
One host:
Assigned list: put IPs in targets.txt, one per line.
Explicitly assigned subnet:
No response does not establish that a host is offline. A list of assigned hosts does not imply the surrounding subnet is in scope.
Why it works
Discovery probes identify responders; silence can be caused by filtering. A known assigned host can still require a port scan that skips discovery.
Worked example · hypothetical
Observation: a known host is absent from the ping sweep. Test: confirm the route and scan its selected application port with discovery skipped. Illustrative output: TCP/443 is open. Interpretation: discovery missed a live service; retain the host and enumerate HTTPS.
New identity, privilege, host or route? Re-enumerate → All topic tasks →