trace a particular IP and port
I have an app running on port 9100 on a remote server serving http pages. After I ssh into the server I can curl localhost 9100 and I receive the response. However I am unable to access the same app from the browser using http://ip:9100 I am also unable to telnet from my local PC. How do I debug it? Is there a way to traceroute a particular IP and port combination, to see where it is being blocked? Any linux tools / commands / utilities will be appreciated. Thanks, Murtaza
6 Answers 6
You can use the default traceroute command for this purpose, then there will be nothing to install.
The -T argument is required so that the TCP protocol is used instead of UDP.
In the rare case when traceroute isn’t available, you can also use ncat .
tcptraceroute xx.xx.xx.xx 9100 if you didn’t find it you can install it
yum -y install tcptraceroute aptitude -y install tcptraceroute Homebrew has a package for this little gem of a tool as well. brew install tcptraceroute . You do need to sudo to use the tool however.
you can use tcpdump on the server to check if the client even reaches the server.
tcpdump -i any tcp port 9100 also make sure your firewall is not blocking incoming connections.
EDIT: you can also write the dump into a file and view it with wireshark on your client if you don’t want to read it on the console.
2nd Edit: you can check if you can reach the port via
Firstly, check the IP address that your application has bound to. It could only be binding to a local address, for example, which would mean that you’d never see it from a different machine regardless of firewall states.
You could try using a portscanner like nmap to see if the port is open and visible externally. it can tell you if the port is closed (there’s nothing listening there), open (you should be able to see it fine) or filtered (by a firewall, for example).
Well, without knowing anything about your application it is impossible to say! Have a look through its configuration file, perhaps? You could try looking at the output of netstat -lt . an application bound to a local address will show up as «tcp localhost:9100», for example.
it can be done by using this command: tcptraceroute -p destination port destination IP . like: tcptraceroute -p 9100 10.0.0.50 but don’t forget to install tcptraceroute package on your system. tcpdump and nc by default installed on the system. regards
If you use the ‘openssl’ tool, this is one way to get extract the CA cert for a particular server:
openssl s_client -showcerts -servername server -connect server:443
The certificate will have «BEGIN CERTIFICATE» and «END CERTIFICATE» markers. If you want to see the data in the certificate, you can do: «openssl x509 -inform PEM -in certfile -text -out certdata» where certfile is the cert you extracted from logfile. Look in certdata. If you want to trust the certificate, you can add it to your CA certificate store or use it stand-alone as described. Just remember that the security is no better than the way you obtained the certificate.
After getting the certificate use keytool to install it.
Trace port on linux
NAME
tcptraceroute - A traceroute implementation using TCP packets
SYNOPSIS
tcptraceroute [-nNFSAE] [ -i interface ] [ -f first ttl ] [ -l length ] [ -q number of queries ] [ -t tos ] [ -m max ttl ] [ -p source port ] [ -s source address ] [ -w wait time ] host [ destination port ] [ length ]
DESCRIPTION
tcptraceroute is a traceroute implementation using TCP packets. The more traditional traceroute(8) sends out either UDP or ICMP ECHO packets with a TTL of one, and increments the TTL until the destination has been reached. By printing the gateways that generate ICMP time exceeded messages along the way, it is able to determine the path packets are taking to reach the destination. The problem is that with the widespread use of firewalls on the modern Internet, many of the packets that traceroute(8) sends out end up being filtered, making it impossible to completely trace the path to the destination. However, in many cases, these firewalls will permit inbound TCP packets to specific ports that hosts sitting behind the firewall are listening for connections on. By sending out TCP SYN packets instead of UDP or ICMP ECHO packets, tcptraceroute is able to bypass the most common firewall filters. It is worth noting that tcptraceroute never completely establishes a TCP connection with the destination host. If the host is not listening for incoming connections, it will respond with an RST indicating that the port is closed. If the host instead responds with a SYN|ACK, the port is known to be open, and an RST is sent by the kernel tcptraceroute is running on to tear down the connection without completing three-way handshake. This is the same half-open scanning technique that nmap(1) uses when passed the -sS flag.
OPTIONS
-n Display numeric output, rather than doing a reverse DNS lookup for each hop. By default, reverse lookups are never attempted on RFC1918 address space, regardless of the -n flag. -N Perform a reverse DNS lookup for each hop, including RFC1918 addresses. -f Set the initial TTL used in the first outgoing packet. The default is 1. -m Set the maximum TTL used in outgoing packets. The default is 30. -p Use the specified local TCP port in outgoing packets. The default is to obtain a free port from the kernel using bind(2). Unlike with traditional traceroute(8), this number will not increase with each hop. -s Set the source address for outgoing packets. See also the -i flag. -i Use the specified interface for outgoing packets. -q Set the number of probes to be sent to each hop. The default is 3. -w Set the timeout, in seconds, to wait for a response for each probe. The default is 3. -S Set the TCP SYN flag in outgoing packets. This is the default, if neither -S or -A is specified. -A Set the TCP ACK flag in outgoing packets. By doing so, it is possible to trace through stateless firewalls which permit outgoing TCP connections. -E Send ECN SYN packets, as described in RFC2481. -t Set the IP TOS (type of service) to be used in outgoing packets. The default is not to set any TOS. -F Set the IP "don't fragment" bit in outgoing packets. -l Set the total packet length to be used in outgoing packets. If the length is greater than the minimum size required to assemble the necessary probe packet headers, this value is automatically increased. -d Enable debugging, which may or may not be useful. --dnat Enable DNAT detection, and display messages when DNAT transitions are observed. DNAT detection is based on the fact that some NAT devices, such as some Linux 2.4 kernels, do not correctly rewrite the IP address of the IP packets quoted in ICMP time-exceeded messages tcptraceroute solicits, revealing the destination IP address an outbound probe packet was NATed to. NAT devices which correctly rewrite the IP address quoted by ICMP messages, such as some Linux 2.6 kernels, will not be detected. For some target hosts, it may be necessary to use --dnat in conjunction with --track-port. See the examples.txt file for examples. --no-dnat Enable DNAT detection for the purposes of correctly identifying ICMP time-exceeded messages that match up with outbound probe packets, but do not display messages when a DNAT transition is observed. This is the default behavior. --no-dnat-strict Do not perform any DNAT detection whatsoever. No attempt will be made match up ICMP time-exceeded messages with outbound probe packets, and when tracerouting through a NAT device which does not rewrite the IP addresses of the IP packets quoted in ICMP time-exceeded messages, some hops along the path may appear to be unresponsive. This option should not be needed in the vast majority of cases, but may be utilized if it is suspected that the DNAT detection code is misidentifying ICMP time-exceeded messages.
EXAMPLES
Please see the examples.txt file included in the tcptraceroute distribution for a few real world examples. To trace the path to a web server listening for connections on port 80: tcptraceroute webserver To trace the path to a mail server listening for connections on port 25: tcptraceroute mailserver 25
BUGS
No error checking is performed on the source address specified by the -s flag, and it is therefore possible for tcptraceroute to send out TCP SYN packets for which it has no chance of seeing a response to.
AUTHOR
AVAILABILITY
SEE ALSO
traceroute(8), ping(8), nmap(1) 2006 March 28 TCPTRACEROUTE(1)