I have a doubt about the following system architecture:
Lets say we have three machines:
SERVER A
SERVER B
EXTERNAL A
SERVER A is offering some streaming services and its behind an uknown network, so it opens a reverse SSH tunnel to SERVER B on an specified PORT, so SERVER B can access to SERVER A service by http: //localhost:PORT
SERVER B is running linux and openssh server for accepting the tunnel. (this server is public)
The doubt comes when I want to access the streaming service offered by SERVER A from EXTERNAL A via the public SERVER B. Suposing I know the PORT I'd like to achieve something like:
EXTERNAL A -> 'http: //serverB_IP:PORT' -> SERVERB -> 'http ://localhost/PORT' -> Tunnel -> SERVER A service.
To entangle it even more there could be plenty SERVER A servers which opens a Tunnel with SERVER B (each one on a different port correctly managed).
Any idea about how to achieve that?
if you enable
GatewayPorts yes
in your sshd_config on server b then it is possible to connect from the outside to server b and make use of the established tunnel to server a. by default GatewayPorts is disabled and the tunnel will only work locally.
Related
I have a server connected to the network with the ip 192.168.xxx.xxx. I can ping the ip but when i try to access from the browser to the server's localhost, obviusly with the IP, i can't.
What is wrong??
UPDATE!!
There was a network error... not configuration!! Thanks for help! Problem solved!
Check if the port you are trying to connect is open. If it is not, you have to bring up the port first, Example: if you are trying to run an app from tomcat, start tomcat first,
There are multiple reasons why this would happen:
The server is not set up to receive incoming connections. Check your firewall settings
The server isn't publicly visible (Meaning the server will appear to a ping, but all the ports are closed
The server isn't able to make outbound connections, again, check the firewall.
To test ports, either port forward, or put the server in to a DMZ (All ports are open)
Manually attempt a file transfer or another service by using ftp <IP of server>:<port number eg 21) or an SSH tunnel. If the FTP passes, then the HTTP port of the server may be down (port 80/8080).
Verify the router interconnecting your PC and the server isn't restricting local peer crosstalk.
I have 2 linux servers with an app that communicate over a simple telnet protocol (unencrypted).
I would like to force the app to run over some form of encrypted tunnel/etc. Is there a simple way to create a point-to-point encrypted tunnel, and force only my apps' traffic over that tunnel (? (eg: create a virtual NIC thats encrypted traffic) I don't want to route all network traffic over this tunnel.
Use SSH port tunneling. You only need to change the connection (IP and port) on your client end once you have the tunnel set up.
Say system 1 listens on a socket on port AAAA and system 2 connects to system 1. Use ssh tunneling from an arbitrary port (say PPPP) on system 2 to port AAAA on system 1. Now direct the 'app' on system 2 to connect to 127.0.0.1:PPPP and the connection will be tunneled to system 1.
If both system listen and accept connections then also setup a tunnel in the opposite direction.
For completeness setup a custom user on both systems for your ssh tunnel. Set the new users login shell on both systems to /sbin/nologin and do not put them in any groups beyond their own. Now use 'sudo - u ' to launch ssh on system 2. Also block traffic from external interfaces to port AAAA on system 1, assuming you no longer need it. Also set ServerAliveInterval and ClientAlivalInterval in your ssh and sshd configurations respectively.
The alternative to this configuration is to set up a VPN between the two boxes.
[Server A] ----- [FTP server] ---- [Server B]
Server A and B can both see the FTP server but not each other. Is there a way to create a tunnel between them through the ftp server, only using the FTP protocol?
FTP will only transfer data to disk or from disk, so the only way to tunnel anything is to store the data on one side and retrieve them on the other side.
You need to install a FTP Proxy on the FTP server, maybe your server already supports proxy connections. This allows Server A to connect to FTP Server and use it as a proxy to connect to Server B and vice versa.
Once Server A has connected to the FTP Server, the FTP Protocol allows to send the command USER <user>#ServerB which will result in FTP Server connecting to Server B and function as a proxy from now on.
I have some experience with FileZilla and it worked fine for me testing a FTP Proxy Product as it offers a lot of the supported mechanisms how to tell a FTP Proxy to connect to the destination server. It also displays all FTP Commands which will be send over the wire, which really helped a lot in troubleshooting.
I have the following network:
PC1 --|¯¯¯¯¯¯¯¯¯| |¯¯¯¯¯¯¯¯¯|-- board2
PC2 --| gateway |-- (eth0) [server] (eth1) --| gateway |
PC3 --|_________| |_________|-- board1
As you can see, the server (running Linux) has 2 interfaces so that the PCs and embedded boards are not on the same subnetwork.
I would like to develop a simple application (or use an existing one) that tunnels incomming Telnet connections from eth0 (using a specific port) to boards through eth1.
I don't have root privileges on the server, but I have a regular Unix account. I don't want the PCs to actually "log in" to the server; I just want them to pass through it to connect to the boards. The server has Python, PHP and Perl installed.
I want to support multiple connections. The port number could be used to forward the connection to the right board (say I have 10 boards, then the tunnel listens on ports 3000 to 3009).
I can imagine a simple Web application to do that, but I want a native Telnet connection that will support CTRL+C and all that stuff and allow you to use any terminal emulator on the PCs (i.e. PuTTY or another one), which run Windows.
Any help would be much appreciated.
It sounds like you're looking for a TCP proxy. A proxy accepts connections on one port, connects to another ip/port, and then passes traffic back and forth.
If you have xinetd on your system you already have what you need. The redirect directive for a service causes xinetd to open a connection to another host/port and act as a proxy. See this document for an example.
balance is another very simple proxy tool that will do what you need. This is probably easier to run as a non-root user, especially since it's configured entirely on the command line.
Since you're not root on your server you'll need to run these on ports > 1024, but otherwise you should be all set.
This is not really a programming question, but I am at my wit's end ...
I am trying to configure a IIS 6.0/Windows Server 2003 web server with a ASP.net application.
When I try to ping the server from client computer A I get the following:
PING 74.208.192.xxx ==> Ping fails
PING 74.208.192.xxx:80 ==> Ping succeeds!
From client computer B, BOTH the pings fail.
PING 74.208.192.xxx ==> Ping fails
PING 74.208.192.xxx:80 ==> Ping fails with a message
"Ping request could not find host 74.208.192.xxx:80"
Both clients A and B are on the same subnet. The server is outside (a virtual server hosted by an ISP)
I have an ASP.NET application in a virtual directory on the server. In IE or firefox, if I enter http://74.208.192.xxx/subdir/subdir/../Default.aspx, it works from both the clients!
The server has default firewall settings but web server enabled (Port 80 is open).
Isn't this better suited for serverfault?
As long as the web app is working fine, why are you "at your wit's end" over ping? Why do you need it?
You don't "ping" a port; ports are abstractions in TCP and UDP, but not present in ICMP, the protocol used by ping; so I have no idea how PING 74.208.192.xxx:80 "succeeds". Could you post a text log of what you see on-screen?
Check to see if the server is blocking ICMP, you'll have to fiddle with firewall settings in Windows to check this.
Also, make sure you can ping from both computers (A and B) to an external, known-good host (I recommend pinging yahoo.com) to see if a local firewall isn't blocking your pings.