I'm using GCP like in the following schema:
TCP balancer -> backend-service -> MIG(my app) with auto scaling.
"My app" accepts commands on a TCP port (A) and sends notifications on another TCP port(B) for subscriber.
I'm running my tests against TCP LB's IP - my tests connect to port B on a startup(i.e. one of instances of "my app") and also my tests make a connection to port A for each test.
i.e. I've faced with a case when port A and port B are terminated/connected to different hosts.
I am not sure how to circumvent this case.
I have mitigated the issue using --session-affinity=CLIENT_IP for backend-services configuration, I.e. all connections from one IP are directed to the same target.
Related
How does SSH dynamic forward (-D) function under the hood?
I understand that SSH dynamic forward opens a SOCSK4 proxy on the local host, and that each connection to the SOCK4 proxy is forwarded over the SSH tunnel to the remote destination.
Does SSH intercept the connections to the SOCKS4 proxy? I mean, it cannot be a "normal" SOCKS4 proxy, because then it would directly proxy the connections to the remote hosts.
Furthermore, how does SSH handle responses from the remote hosts, i.e., how does it transfer them back over the SSH tunnel to the recipients on the local host?
When the -D flag is given, the SSH client will start a built-in SOCKS4/5 proxy. (note: "SOCKS", not "SOCK").
-D [bind_address:]port
Specifies a local “dynamic” application-level port forwarding. This works by allocating a socket to listen to port on the local side, optionally bound to the specified bind_address. Whenever a connection is made to this port, the connection is forwarded over the secure channel, and the application protocol is then used to determine where to connect to from the remote machine. Currently the SOCKS4 and SOCKS5 protocols are supported, and ssh will act as a SOCKS server.
When another application wishes to connect to a proxied service, they will establish a connection via this SOCKS server. The SOCKS protocol is a little bit of negotiation that occurs at the beginning of a connection, something like this: (inspired by the wiki page)
ssh -D 1234 user#remote is execute, the SSH client starts a SOCKS proxy server listening on port 1234.
A local application wishes to communicate with a service via the SOCKS proxy, so connects to port 1234.
The SOCKS client asks for a connection to a particular IP address and port - e.g: 66.102.7.99, port 4321.
The SOCKS server, in this case the SSH client, will negotiate to establish this onward connection with it's server (remote, from above). This may fail.
The SOCKS serve will respond to the client with success / failure information.
If successful, all data passed through this socket will now be forwarded appropriately:
From the local application, to the SSH server (remote), and then onto 66.102.7.99.
From 66.102.7.99 to the SSH server (remote), and then onto the local SSH client, and ultimately the local application.
Does SSH intercept the connections to the SOCK4 proxy?
No, the SSH Client is the SOCKS proxy.
I mean, it cannot be a "normal" SOCK4 proxy, because then it would directly proxy the connections to the remote hosts.
I suppose it's not really - the SSH Client and Server act together to achieve the function of a "normal" SOCKS proxy. The high-level result is that the proxy listens on one host, but forwards data from another host, with a magical link in between.
Furthermore, how does SSH handle responses from the remote hosts, i.e., how does it transfer them back over the SSH tunnel to the recipients on the local host?
TCP is a connection-oriented method of communication. That is to say that once a connection is established, data can flow in both directions, and is reliably identified as "related to that connection". With this information it is trivial to associate the data with arbitrary rules such as "forward to the SSH server, who will forward to 66.102.7.99".
I am working on a project consisting of the bidirectionnal (and secure) connexion of a lot of Raspberry PI -N clients- to a known, accessible, fixed-IP adress Server.
The clients (Raspberry PI) are all connected to the Internet via a classic NAT. Let say clients are identified by a number between 1 and N.
[Client] Raspberry PI <-> NAT (Internet Provider) <-> Internet
All client's public IP are dynamic
The Server is located somewhere on the Internet at the IP address A
--- My GOAL : Connect each client to the server with the SSH protocol. ---
The Server needs to send data at will to any client (no broadcast), and each client needs to send data to the server.
There will be "N" SSH tunnels, initiated by the clients , using reverse-port forwarding or/and port forwarding.
That's where i lack knowledge in SSH:
1) How can the server associate each tunnels with a client in
order to be able to use the proper tunnel ? How can a program (for
example in C) identify and "use" each tunnel for sending and receving
server-side?
2) Using [reverse] port forwarding, what are the needs in ports
server side, does each clients needs a remote port on the server?
3) Do i need to create a program that link each outgoing port to a
client ID and same thing for ingoing port?
My problem is when the server needs to send data to a specific client, how to do it ?
Thank you very much.
I open IE explorer & Chrome in my computer and type localhost:80 and I get the index page.
Here I think my machine's IP is same to both connections (IE explorer & Chrome) and ports are too (80).
Note: Source port will be different (as destination is same: localhost IP), this is my second question.
So how webserver (lets say apache) handles this port 80 connections without failing? Does it port forwarding? In OS level even I tried with addr re-use, port re-use parameters and it is all same we cannot make multiple connection with same IPs & ports.
Now, probably you have came up with a solution: although source ports and IPs are same, destination port is different in package: <protocol>, <src addr>, <src port>, <dest addr>, <dest port>.
A. I got 49483~50004 ports as you can see on image. How client knows which destination port (49483~50004) is bound by webserver? If it is random between 0 and 65355 the webserver always binds all ports, it is very resource consuming. How webservers avoid from this?
Look at this image: command prompt-> netstat
If this question is related with low level sources it is OK, I understand Embedded TCP/IP/UDP, Phy MAC communication and package structures.
You have this all back to front.
All the port numbers at the server are the same: 80. So the client only has to know port 80.
All the port numbers at the client are different: 49483-50004 etc. So there is no ambiguity in the connection, because the 4-tuple you mentioned is unique.
All http request by default call to servers in the port 80, because servers listen by default in that port. So you only give an IP or hostname and the web browser add the default port (80). You can give a custom port if you web server is listenning in another port (usually Tomcat listen by default in 8080) for example you call it in: http://www.youamazingweb.com:8080.
A good example is see the IP as the home and the port is the door where clients enter to consume some resource hosted in server.
I was looking for an answer on my question on google and also here, but a didn't find a proper answer.
So here is the context:
I have a software running on some server (without firewall) in one subnet.
There is another software running on some PC in a different subnet.
Both subnets are connected to a gateway server. All computers are running CentOS or RHEL.
On the gateway server, there is a firewall, preventing multicast traffic from leaving the one subnet and allow clients from outside to connect to computers inside this subnet. Therefore xinetd is used. The computer from outside needs to send a packet to a specific port, the computer on the inside answers to another specific port depending on the sender. So there is no need for the gateway to keep track of sender-receiver relations. It just needs to forward UDP on specific ports to specific computers from one subnet to another.
So I added one service in /etc/services (for one direction):
udp-gateway 6000/udp
And created the according configuration file in /etc/xinetd.d/gateway like:
service udp-gateway
{
disable = no
socket_type = dgram
protocol = udp
wait = no
user = root
redirect = 192.168.1.1 6000 #Server inside the 192.168.1.0 subnet
}
Now the problem is, that the server doesn't open an UDP-port to listen on ('netstat -nulp' says). When I change the protocol to TCP and the socket_type to stream, it works. But I need this for UDP.
Is it possible that this is not possible for UDP? Or is netstat just not showing the ports? Or is my xinetd-configuration missing something?
Thanks in advance, every hint is appreciated.
Benny
redirect = 192.168.1.1 6000 #Server inside the 192.168.1.0 subnet
from the man page of xinetd:
redirect
Allows a tcp service to be redirected to another host.
This means usage of redirect for udp is not possible. And I don't see any other way to do this with xinetd.
It's not that much of a question, rather a confirmation that what I did is right or not and if it is safe or not.
Until now what I have found googling around is that you cannot run rtorrent through a proxy. You can either put the http request through a proxy, or tsocks, in both cases either the actual transfers are done directly or not done at all. Therefore until now the only proposed viable solution is a VPN which I wanted to avoid.
What I did was use an http proxy for the http part and a port forwarding for the actual download part. For example, lets assume the following:
192.168.1.10 --> Local machine with the actual rtorrent
remote.machine.com --> The remote machine used as a proxy
Procedure:
I created 2 ssh tunnels
ssh -N -D 9090 user#remote.machine.com
ssh -R 9091:localhost:9091 user#remote.machine.com
From the local machine I installed polipo as the html proxy and configured it to use a socks proxy in the remote.machine.com.
I edited the following lines in /etc/polipo/config so that I can get the socks proxy.
socksParentProxy = "localhost:9090"
socksProxyType = socks5
I also changed the html proxy port for extra security, again in /etc/polipo/config
proxyPort = 9080
On the local machine I changed the ~/.rtorrent.rc as following:
#Proxy of the http requests through polipo
http_proxy=localhost:9080
# The ip address reported to the tracker.
#Really important, in order to get connections for downloads
ip = remote.machine.com
# The ip address the listening socket and outgoing connections is
# bound to.
bind = 192.168.1.10
# Port range to use for listening.
port_range = 9091-9091
# Start opening ports at a random position within the port range.
port_random = no
The system seems to work. I connect to the trackers and I have up and down traffic. So the questions are:
Am I safe that all the traffic concerning rtorrent is done through the remote.machine.com?
Did I miss something?
Are there any problems or concerns regarding this method?
As far as I see, you have covered inbound connections, as well as outgoing HTTP traffic, but any outbound peer-to-peer connections will be created directly, not through any tunnel. Currently, rtorrent does not appear to support passing outbound P2P connections through a tunnel or proxy of any kind, so in order to handle these, you'll need some other mechanism.
You mentioned tsocks and that it does not work – not even in addition to the rtorrent configuration you have set up above? (Although with tsocks you should be able to drop the HTTP proxy part.)
If that fails, there are alternatives to tsocks mentioned on the tsocks project page. A slightly more involved alternative would be to create a new loopback interface (lo:1 with IP 127.0.0.2), bind your rtorrent to that one and use something like sshuttle to direct all traffic originating on that interface through an SSH tunnel. Unfortunately, sshuttle doesn't let you restrict its operation to a specific interface at the moment, though, so you'd have to fiddle with the iptables rules it creates to make them match your needs. I assume a patch adding this feature to sshuttle would be welcome.
As a side note, you can create multiple port forwards and SOCKS proxies in a single SSH connection, like this:
ssh -N -D 9090 -R 0.0.0.0:9091:localhost:9091 myself#my.example.com