Unable to establish TCP connections with server - linux

I have 2 centOS-7 machines say machine A,B.
Machine A have a server listening on port 80. When i run curl-loader(for load testing purpose) with 2000 request per second in the same machine, all the request is hitting the server, i checked 'ss -s' command and open TCP sockets is more than 2000.
But my problem is when i run curl-loader in machine B and try to hit server A only few requests are reaching server, remaining all are dropping out.
in machine B 'ss -s' command returns 2K+ value. but in machine A 'ss -s' command will return only value 25-30. Remaining all request are returned are TCP-CONNECT error

#arkascha is probably right. Some throttling is happening. I would only add that the throttling could be in the network, in the server OR in the client. Any of them could be throttling the number of connections.
It's better to test it without any squid or high level software. You can just do:
(On server) $ echo hello | nc -l -k 10000
(On client) $ for ((i=0; i<2000; i++)); do nc :10000 & done
This will create a "mini" TCP server on the server machine on port 10000. Anyone that connects to that server will receive the message "hello".
Then from the client, you can create 2000 (almost simultaneous) TCP connections to the server on port 10000.
If the connections are successfully established, then the throttling is probably at the "proxy" level. If the connections appear throttled, then the throttling is likely at the firewall or network level.

Related

Reliable way to get max information about remote open port after handshake?

Some of services shout about themselves immediately after connection is made. For instance:
cat < /dev/tcp/127.0.0.1/22
SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.4
^C
It does not matter if the sshd will run on port 65000 or 22 the message is the same. However:
cat < /dev/tcp/127.0.0.1/27017
^C
Does nothing. Even the port is active and running.
How can we trigger similar messages (outputs) for any other service ports, let's say of databases 3306/5432/27017 without specific database connectors? Programming language or tools does not matter as well.
Thanks.

Finding out what process opened a short-lived port

So, I've got a CentOS6 host where some process has cached an old DNS server, and I'm trying to find out what process that is. (Let's say I can't go blindly rebooting servers and I need to physically confirm what program making requests to this old DNS server).
I've been looking at the outgoing DNS traffic from said host to the old DNS server, and it's originating from some short-lived ephemeral port that opens and closes immediately after, and I'm trying to figure out what process requested it.
example:
$ tcpdump -i eth0 port 53 | grep "> old.dns.host"
19:26:33.442632 IP my.host.46133 > old.dns.host.domain: 56541+ PTR? 49.6.123.10.in-addr.arpa. (42)
my.host is still reaching out to the old DNS server old.dns.host, over the ephemeral port 46133. But when checking netstat, that port is gone. Even watching netstat and using -c don't pick anything up.
So in general -- if I have a port that opens only for a few milliseconds for the duration of a request, how do I find out what process opened it?

UDP send test fails on amazon ec2 - all outgoing traffic enabled

I'm running an ubuntu 14.04 instance on amazon ec2- I can't seem to send any udp packets from my instance to my local machine.
Running the followings commands:
On amazon ec2 instance:
echo "test" | netcat -vu m.y.i.p 5500
Connection to m.y.i.p 5500 port [udp/*] succeeded!
On my local machine:
netcat -luv 5500
Listening on [0.0.0.0] (family 0, port 5500)
So we successfully make a connection, but I never receive the test packet on my local machine.
Is there anything else I might need to configure with my instance for this to work?
A UDP transmission does not have a connection (as does TCP) so the message "Connection to m.y.i.p 5500 port [udp/*] succeeded!" doesn't really tell you much about the true success of the transmission of a packet from A to B. It might have never even left the originating machine (due to some firewall rule).
In my experience most common UDP problems are firewall blocks at the incoming machine so you certainly need to check on any firewall rules that might be blocking UDP incoming on port 5500.
If that looks ok, then the easiest way to debug is to use a packet sniffer (tcpdump, wireshark or similar). First confirm that a UDP packet is leaving your source machine, then try to see it incoming on the target machine.
tcpdump host m.y.i.p

A proxy that bridges simultaneous clients to a single connection

I am looking for a tool (under linux) that will allow me to set up an end to end proxy that accepts multiple simultaneous clients on one port at one end, forwards the data to the other end with a single connection then "expands" the connection at the other end to connect back to a service that accepts multiple connections. To clarify, here is a diagram of what I want to achieve:
http://i.stack.imgur.com/rgTMd.png
(apparantly I need more then 10 rep to have the image embedded in this page)
If you're interested, the reason why I am attempting to do this is because I want to build a system that would make it easier to tunnel over arbitrary protocols, as long as the protocol supports some way to send some message from one end to another. I would put the system in between proxy end A and proxy end B in the diagram above.
Here is an example of how I want it to work:
First I will run the following commands
mkfifo backpipe
nc -l 7778 0<backpipe | tee f1 | nc localhost 7777 | tee f2 >backpipe
The "server proxy" will be running on port 7777.
The "client proxy" that the application will connect to will be running on port 8080
The client proxy will connect to port 7778
Solve for "server proxy" and "client proxy"
OpenSSH already supports this with the -D option:
ssh -D <port> -l username remotehost
A SOCKS server will listen for connections on and forward them to the other end of the SSH connection.
I've decided to code my own solution for the mean time. It's a bit of python code that accepts multiple clients and basically proxies the communication through the standard input/output. If anyone is interested, here's the code http://pastebin.com/1E45Exsy
Don't trust this code to work perfectly. I have not tested it properly and it doesn't handle disconnecting clients.
I will continue to search for a more elegant and robust solution, but this should do in the meantime. I'll post updates to the code here if I make them.

Unable to ping server from client B but able to ping from client A. Please help

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.

Resources