I have an hadoop defaultFs application run in port 8020, as show with sudo netstat -tulpn | grep :8020, where 10.44.142.19 is the internal address,
tcp 0 0 10.44.142.19:8020 0.0.0.0:* LISTEN 31680/java
I also opened this port in iptables
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8020
But this port is still blocked.
I guess is the problem of ip address, where 10.44.142.19 should be 127.0.0.1, because I am visiting it from external, right?
How could I solve this? Thanks in advanced.
ok if you are coming in from the WAN you need to use your ip from your modem. google "whats my ip" If you are behind a router, your router will give you an ip of something like, 192.168.10.101 type that in goto your sever over a LAN.
:8020 at the end if that is your port you are directing to.
firewall must be down for that port to come from the outside, and your web server must be setup to make the files and folders you want to disturb or make available with permission of at least read for your web servers user or group, in permissions.
each system is a little different so you have to tweek things as you go.
Related
I made a nginx server at 192.168.1.106 and I can access it from the host computer but it doesn't show when I access it on a computer in the same network. But I can ssh into the server from a different computer using the same address. I checked my firewall to make sure it isn't blocking anything.
How do I access the server form a different computer?
> iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
The server_namedocs directive is used to identify virtual hosts, they're not used to set the binding.
netstat tells you that nginx listens on 0.0.0.0:80 which means that it will accept connections from any IP.
If you want to change the IP nginx binds on, you have to change the listendocs rule.
So, if you want to set nginx to bind to localhost, you'd change that to:
listen 127.0.0.1:80;
In this way, requests that are not coming from localhost are discarded (they don't even hit nginx).
I can't connect to tomcat9 from outside (by ip)
i disabled tcp6 (add to /etc/sysctl.conf) following
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1
netstat -nlp output:
tcp 0 0 127.0.0.1:8005 0.0.0.0:* LISTEN 7460/java
tcp 0 0 0.0.0.0:8009 0.0.0.0:* LISTEN 7460/java
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 7460/java
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 1118/nginx
server.xml Connector block:
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
address="0.0.0.0" />
I also tried to add useIPVHosts="true" to <Connector> and resolveHosts="true" to <Valve> block in server.xml, but still nothing.
I'll be thankful for all of your answers)
From what you have provided, your Tomcat server is running on a laptop in your home network. Your friend is trying to access this over the internet but is not able to. Assuming your configuration for Tomcat is correct we can narrow it down to a couple areas.
Your server is not accessible via the internet:
You cannot just provide a public IP to your laptop and expect it to work on the internet. Home networks are setup in a way to preserve public IP addresses which are paid for by big companies (Comcast, Verizon, etc.). Your router will be assigned a public IP address accessible from the internet and all of your internal nodes (phone, computer, laptop etc.) will have an internal (192.168.x.x) address assigned to them available via NAT handled by the router itself. In order to access your internal nodes via the internet you will have to login to your router and enable some port forwarding. You should also enable dynamic DNS which routers should allow you to use (http://yourserver.something.something instead of router IP). For port forwarding in your router, you should have an option to set (for example) port 50001 --> IPofTomcat port 8080. Your friend would then access your webpage via your routerIP/50001/jspname.jsp
You could potentially get a static IP from your ISP but then you are looking at monthly fee's (go with port forwarding and dynamicDNS). Your router should be able to handle reserved IP's as well.
Firewall issues:
Ensure that there are no inbound/outbound rules that can affect traffic on your server/router. I doubt your router would have these by default (not really a good thing ;) ), but this is something to consider if you know port forwarding is setup and working correctly.
Additional comments:
I am going to say this just for general knowledge if other people go to this post. Ensure these steps are accomplished prior to hosting an at-home web-server.
Change default passwords for everything! That includes Apache, router, local accounts. Harden every password in your network especially if you are opening up communication to host a web-server.
Apply any and all software updates/patches to your tomcat server.
Good idea to change default ports if this will only be used by a few friends)
Ensure your directory is locked down (jspname.jsp resides in)
Make a backup prior to going live.
Monitor access logs on router/server regularly.
I am trying to understand a setup and have highly confused my self.
Say my box IP is xx.xx.xx.xx and the 127.0.0.1 is Local Loopback of my Linux box. Now when I do a netstat for a port I see below output:
tcp 0 0 127.0.0.1:11191 0.0.0.0:* LISTEN 9999/myexe off (0.00/0/0)
tcp 0 0 xx.xx.xx.xx:11191 0.0.0.0:* LISTEN 26998/anotherexe off (0.00/0/0)
What does the output basically means - since 127.0.0.1 and xx.xx.xx.xx refers to same box then does it means that two executable have binded and running at same port is same box - if so which binary would service the request if coming at port 11191 in my case?
Each of those is almost certainly a different interface and hence a different internet address. That is, 127.0.0.1 is typically the loopback interface. While presumably xx.xx.xx.xx is a real (ethernet) network interface. It is entirely possible to have two separate programs bound to the same port number on separate addresses. It is more common that a single program simply binds to the port number and the kernel in effect translates that into multiple binds, one for each interface's address.
See bind(2) and ip(7) manual pages for details. Specifically, INADDR_ANY is the pseudo-address that can be used by a server that wishes to bind the port on all interfaces.
See also the answer here under the first paragraph of the Linux subheading:
Socket options SO_REUSEADDR and SO_REUSEPORT, how do they differ? Do they mean the same across all major operating systems?
On some platforms, netstat can show you the processes that own the sockets. For example, on Windows, the -b switch displays executable names, and the -o switch displays process IDs. On Linux, the -p switch displays process information.
does it means that two executable have binded and running at same port is same box
Yes. Your netstat output includes process names, so we can clearly see that myexe is listening on 127.0.0.1:11191 and anotherexe is listening on xx.xx.xx.xx:11191.
if so which binary would service the request if coming at port 11191 in my case?
It depends on which local IP the connection arrives on. 127.0.0.1 is a loopback adapter, so only clients running on the same machine can connect to it. If a client connects to port 11191 on 127.0.0.1 specifically, myexe will handle the connection. If a client connects to port 11191 on xx.xx.xx.xx, anotherexe will handle the connection.
I have a Node.js server listening on port 9000
Internally I can run "curl localhost:9000"
And it can retrieve the GET request.
But when I try and connect to the IP from the outside on port 9000, it doesnt work.
Do I need to open the port publicly?
Its an Amazon EC2 instance.
What do I need to do?
SOLVED:
had to add tcp inbound into security groups. Thank you very much
VALUES:
Custom TCP Rule
TCP
0 - 9000
0.0.0.0/0
Sounds like a firewall issue. There are two things to look for, first is IPTABLES, which will show you the firewall rules on the local server. https://help.ubuntu.com/community/IptablesHowTo
With AWS instances, they also belong to Security Groups, and you will have to edit this security group to allow traffic on port 9000 as well. http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html
I'm trying to connect to a service, and to debug it, I ran
netstat -nap | grep LISTEN
The results should rows of two types :
tcp 0 0 127.0.0.1:8020 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:57140 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:11000 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:8088 0.0.0.0:* LISTEN
unix 2 [ ACC ] STREAM LISTENING 4512 -
unix 2 [ ACC ] STREAM LISTENING 9760 -
I have 3 questions :
1) I want to connect to the process running on 127.0.0.1 --- how can I do this externally ? I have read elsewhere that 127.0.0.1 processes are only allowed to communicate with other localhost processes.
2) What is the difference between the "tcp 0" netstat records and the "unix 2" ones ? Im somewhat naive about networking, so feel free to overexplain this one :)
In short, your process is bound to a loopback interface which cannot receive packets from an external network. You'll need to reconfigure the process bound to port 8020 to bind to an external interface to be able to connect to it from another host.
The long answer is that the two addresses you site (127.0.0.1 and 0.0.0.0) are both special in certain ways, and it is useful to understand what you're seeing.
Addresses in the 127.0.0.0/8 Internet Protocol address block (of which 127.0.0.1 is one) are reserved for use internally on a host. See rfc5735 for details, but there's nothing special about these addresses except that all IP hosts use the same rules and aren't setup to route these addresses outside a host or router.
On your computer, you'll usually see a special "loopback" network interface that has 127.0.0.1 assigned.
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
This interface is special and never connected to an external network. It is used when a program wants to connect to a service on the local machine as 127.0.0.1 will almost always be configured as an active network interface. Packets will only arrive on this interface if they are sent from a local process.
The other address you site, 0.0.0.0 is special and usually represents all IP addresses mapped to any network interface on your computer. When a program wants to listen for connections arriving on any network interface or IP address, it will bind a TCP/UDP port to 0.0.0.0 to listen for connections.
In your case, however, you're reporting netstat output listing 0.0.0.0 on lines describing TCP sockets in a LISTEN state. In this case, netstat is listing sockets listening for connections and using 0.0.0.0:* as a place holder for the foreign address field of it's output. In this case, 0.0.0.0:* signifies that the socket is waiting for a connection from any host.
Regarding your question on "tcp 0" vs. "unix 2", these are the first two columns of your netstat output. A look at the column headers from your netstat command is useful:
# netstat -nap | head -2
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
What you're reporting as "tcp 0" simply means a socket using the TCP protocol has zero bytes in the received queue waiting for the program connected to this socket to consume. Similarly, "unix 2" is what's called a unix socket with two bytes waiting in its receive queue for the connected process to consume.
TCP sockets are part of the TCP/IP stack that can be used locally or across IP networks for processes to communicate. UNIX sockets, on the other hand, are simpler and only used for what's called IPC or inter-process communication which only happens between two processes both running on the local system, and there's no networking involved (no addresses and ports anyway). UNIX sockets are considered to be more efficient than TCP sockets, but they are obviously more limited in function. On UNIX-like systems UNIX sockets are implemented as a file on the file system of a special "socket" type that both processes using the socket read and write to as a communication channel.
1) Without binding it to 0.0.0.0, you can still access the service through a tunnel. This is similar to using a proxy as David Schwartz mentioned. There's a few assumptions I'm making for this example:
The server is running a service bound to 127.0.0.1:8020, we'll call it 'myservice'.
The server is running OpenSSH server 'sshd' on the default port of TCP 22, and the user can log in with the username 'myusername'.
The client is running a system with OpenSSH client installed.
The server is accessible via the IP address of 10.20.30.40.
On the client, SSH to the server with the following command:
ssh -L 12345:localhost:8020 myusername#10.20.30.40
Once you log in, minimize the SSH window. In another window on the client, run netstat to find listening ports. You should see 127.0.0.1:12345, just like on the server.
On the client, connect to the service on 127.0.0.1:12345. You should now be connected to the 'myservice' instance on the server, even though you made the connection to the client's local loopback interface.
The trick here is that SSH is tunneling a listening socket on the client to the listening socket on the server. I've made the port numbers different for clarity.
1) You would either need to modify the server to bind to a publicly accessible address (or 0.0.0.0) or run a local proxy to handle the connection.
2) TCP connections use the TCP protocol, the one used for connection-oriented traffic on the Internet. UNIX connections use a strictly local protocol that is much simpler than TCP (because it doesn't have to deal with dropped packets, lost routes, corrupted data, out of order packets, and so on).
1) You cannot (if you mean from another machine - 127.0.0.1 is localhost and by definition you can only connect to it from the local machine
2) The first column shows the domain of the sockets - tcp are tcp sockets and unix are unix domain sockets.
And as for the answer to you question 3 ;-)
3) 42