I'm looking for a tool that converts my tcp connection into a proxy (https). The application should run on an extra server. It should be for Linux and possibly run as a container
Example:
Application --> tcp-data [server] --> https (proxy protocol) --> [proxy server]
Anyone know anything like this?
Many thanks for the help!
Related
I have a HAProxy configured that works as expected when sending requests directly to the proxy host and port that the proxy is listening on. The proxy is running in TCP mode.
frontend tcp-in-mssql
bind :5650
mode tcp
use_backend mssql
backend mssql
mode tcp
server mssql01.mydomain.com mssql01.mydomain.com:5650 check
When I try to send requests to the proxy by using the SOCKS_PROXY or ALL_PROXY env vars, the proxy isn't used and the connection is made directly.
example:
SOCKS_PROXY=socks://localhost:5650 my_command --target=mssql01.mydomain.com:5650
ALL_PROXY=socks://localhost:5650 my_command --target=mssql01.mydomain.com:5650
The proxy is bypassed and a TCP connection is made directly to the target host. Though if do something like my_command --target=localhost:5650 the TCP connection goes through the proxy and is made successfully to the backend target server.
How can I route traffic to the proxy?
Socks is a specific protocol to be spoken by client and proxy (https://en.wikipedia.org/wiki/SOCKS). Socks allows the client to specify which server to connect to on which port. To do so, the client establishes a connection to the socks proxy, the socks proxy then establishes a connection to the server and forwards the traffic from client to server and vice versa.
Example:
client -> socks proxy (port: 1080) -> server1 (port: clients choice)
-> server2 (port: clients choice)
-> serverN (port: clients choice)
-> server (clients choice)
Your HAProxy configuration configures the haproxy to serve as a reverse proxy for tcp connections on port 5650. Tcp traffic received on port 5650 will then be forwarded to one of the destination servers configured in backend section.
Example:
client -> reverse proxy (port 5650) -> backend (server and port
as defined in haproxy config)
So you already have a working solution for proxying the connection to the mssql backend. Just configure the mssql client to connect to the hapoxy on port 5650.
If you need a socks proxy to suit your use case, you have to replace the haproxy with a dedicated, socks capable proxy solution
I am not able to successfully bind and secure the rethinkdb http client, either being exposed to the whole network or refusing connections behind the proxy.
I am thus left with no choice but to restart the rdb daemon with bind-http=all each
time I want to access it...
Rdb starts with systemctl under archlinux. Three configurations I tried:
# /etc/rethinkdb/instances.d/mydb.conf
bind-http=localhost #(1)
bind-http=127.0.0.1 #(2)
bind-http=1.2.3.4 #(3)
Resulting in:
Fails to parse 'localhost'
Refuses connections behind the proxy
Equivalent to bind-http=all
Firefox 59 uses a socks proxy, working ok
as the browser's ip address does become 1.2.3.4:
$ ssh -TND 8080 user#1.2.3.4
I am quite convinced that I had secured the http client as expected,
and problems started after I updated both FF and rdb
(FF59 fails to parse 'localhost' as well for example)
I don't know if this is a bug or a feature or if I am missing something,
any help is most welcome. Many thanks
Beware of the "localhost" string.
Configuring the rethinkdb server with:
#/etc/rethinkdb/instances.d/mydb.conf
bind-http=127.0.0.1
http-port=8084
and binding some local port with SSH:
[client]$ ssh -L 8080:127.0.0.1:8084 server
is enough to access the web interface at 127.0.0.1:8080, as suggested by #jishi.
Configuring the browser to use a SOCKS proxy as per the rdb docs is not at all necessary.
For some reason localhost:8080 is not understood by FF59 (gets invisibly prefixed by www or something).
Specifically, I have a Windows server (Windows 7), but the netstat -an command only shows whether ports are TCP or UDP. I thought these were the only kinds of ports, but node.js seems to distinguish between HTTP ports and TCP ports (example at bottom of linked page). I'm currently using node.js in a program that will run on my server, and it opens HTTP ports by default. These appear as TCP ports under netstat -an.
Is there a command line trick for distinguishing whether an open port on this server is HTTP or TCP? I make requests to my Information Technology office about ports that I need on this server, and they need to know whether these ports will be TCP, UDP, etc.
If necessary to use a remote client, I have a Mac that can do the job.
HTTP is an application protocol. Its definition presumes an underlying and reliable transport layer protocol. The transmission Control Protocol is commonly used. However HTTP can use unreliable protocols too (example SSDP).
Now to answer to your question:
netstat -lt : List TCP Listening Ports
netstat -lu : List UDP Listening Ports
If you want to know wether a TCP Port is running HTTP or not, you can check the standard port on HTTP (grep :80). The standard HTTP port is 80. The standard HTTPS port is 443.
All HTTP traffic is transmitted over TCP Ports. I think what may be causing some confusion is that the first node.js example uses the http module and the second example uses the net module.
The http module is built on top of the net module (which handles the TCP layer underlying HTTP).
Refer to: nodejs - net or http module
EDIT:
Only one process can bind to a port. If you're having difficulties connecting, shut down any other applications that may be using the same port, such as your Java Hello World server. Run netstat -an to make sure you don't see the port listed that you're trying to listen on in you node.js TCP server (port 1337) in the example. If nothing is listening on the port, fire up your node.js TCP server and run netstat -an again to make sure it's actually listening on the intended port.
Another suggestion - temporarily turn off the software firewall then use the telnet client on the local server to attempt to connect to the port using the command telnet 127.0.0.1 1337 (replace 1337 with your port) from the command prompt. This will eliminate any network devices such as firewalls between the client (telnet in this case) and the server. If the screen goes blank, you've connected. If you get the message Could not open connection to the host, on port then it's still not listening on the TCP Port. If you can connect locally from Telnet but you cannot connect remotely then there is something blocking your connection.
I am trying to find somw Windows based tools that can help me validate TCP and UDP connection on remote machines.
My Problem (just one use case):
At work, I manage many clustered servers that I run load tests against. In order to get a rich test, I use Jmeter-Plugins which provides a Server agent that opens a TCP socket on port 4444 on a target remote machine: http://code.google.com/p/jmeter-plugins/wiki/PerfMonAgent
There are many times when I setup a new load test farm, that either the network, or the server configuration, or the ServerAgent itself can have issues and thus not allowing a Load test client to access that TCP connection.
The issue I have is that I dont know what part of the system is broken.
What I think I need:
I would like to know how I can open a TCP (not HTTP with cUrl), connection to a remote server to validate that the network allows the connection, as well as the Server firewall allows the given TCP connection to be accessed remotely.
What I have looked:
These are some of the tools I have looked at so far:
Nmap http://nmap.org
Ncat http://sourceforge.net/projects/nmap-ncat/
TCP/IP Builder http://www.drk.com.ar
Zenmap 6.01 and nmap might do the job I want, but some machines where not accessible to Zenmap when I know 100% that the server was accessible via HTTP, so that was strange.
I have looked at many tools and either they:
Dont allow remote connections
Dont seem to want to connect to a TCP socket
Or I dont understand the tools to accomplish the validation I stated above.
I would greatly appreciate all comment and suggestions to help with this re-occurring problem I face.
Mick,
Firebind.com can do what you'd like to do. Firebind is an Internet based server that can listen on any of the 65535 UDP or TCP ports. It uses a java based client to send traffic to and from the server from your machine.
Carl
www.firebind.com
First of all, sorry for my bad English : )
My Java application (multiplayer game server) uses this package to communicate with a web application in client's browser using websockets: https://github.com/TooTallNate/Java-WebSocket
I've encountered a problem running my application: only I can connect to the websocket server, clients on other hosts can't do so. In browser I estabilish connection as usual, address here is certainly correct:
new WebSocket("ws://"+serverIp+":8787");
When I connect from my own host to the websocket server running on the same host, it runs perfectly. When other hosts try to connect to me, connection in not being estabilished: in browser WebSocket objects's .readyState is 0 (whilst it should be 1), and even server does not recieve any handshakes (no output from onClientOpen in server console, I even tried to get any output from certain WebSocketServer class' methods).
Other hosts are still recieving, for example, static contents of web application from webserver on 80 port on the same host. Problem is not the closed 8787 port: I checked it, it's open.
What may be the reason that other host can't connect to my websocket server?
WebSockets uses a cross-origin permission system. You might need to tell you WebSocket server to accept connections from more than just your local host. The verification of Origin happens during the WebSocket handshake which likely happens prior to onclientOpen.