I would like to know how many TCP connections are created when WebSocket call is made from browser to apache http server to backend web service?
Does it create a separate TCP connection from the browser to apache http server and from apache to the web service?
When Apache is proxying websockets, there is 1 TCP connection between the client and Apache and 1 TCP connection between Apache and the backend.
Apache watches both connections for activity and forwards read from one onto the other.
This is the only way it can be in a layer 7 (Application Layer, HTTP) proxy. Something tunnelling at a much lower layer, like a NAT device or MAC forwarding IP sprayer could tunnel a single connection -- but not on the basis of anything higher up in the stack like headers.
The 2nd connection is observable with netstat.
The 2nd connection is opened when mod_proxy_wstunnel calls ap_proxy_connect_to_backend() which calls apr_socket_create() which calls the portable socket() routine. When recent releases of mod_proxy_http handle this tunneling automatically, simialr flow through ap_proxy_acquire_connection.
Related
I have a service that exposes an API over an in-house developed TCP protocol. I am currently in the process of moving that service to a REST API. The service listens for and response to requests for both APIs simultaneously as it may be some time until all the clients move over to the REST API.
Given that the APIs are different protocols, I believe I will need both tcp frontends/backends and http frontend/backends.
I would prefer to not have to deploy separate instances of my service for each protocol. Instead, I would like to have the same set of servers for each of the backends and have HAProxy load balance (leastconn) across them.
As an example
frontend fe_custom
bind :11111
mode tcp
use_backend be_custom
frontend fe_http
bind :80
mode http
use_backend be_http
backend be_custom
mode tcp
balance leastconn
server server1 192.168.10.100:11111
server server2 192.168.10.101:11111
backend be_http
mode http
balance leastconn
server server1 192.168.10.100:80
server server2 192.168.10.101:80
So if a request is sent to my custom protocol on port 11111 and gets sent to be_custom:server1, I would like a subsequent request that comes in for my REST API on port 80 to get load balanced to be_http:server2.
Will this scenario just work if the same server is specified in different backends? If not, is this something that can be done in HAProxy?
AWS NLB supports TLS termination
https://aws.amazon.com/blogs/aws/new-tls-termination-for-network-load-balancers/
NLB being a Layer 4 load balancer I would expect it to work in a passthrough mode by directing the incoming packets to one of the backends without much of state maintenance (except for the flow tracking)
Are there any details available on how AWS implements the TLS termination in NLB ?
Is it possible to do it with open source tooling (like IPVS or haproxy) or AWS has some secret sauce here ?
The TLS termination itself is just what it says it is. TLS is a generic streaming protocol just like TCP one level up so you can unwrap it at the LB in a generic way. The magic is that they keep the IPs intact probably with very fancy routing magic, but it seems unlikely AWS will tell you how they did it.
In my SO question here, I have an example of how to terminate a TCP session in HAProxy and pass the unencrypted traffic to a backend.
In short, you need to use ssl in the frontend bind section and both frontend and backend configurations require use of tcp mode. Here is an example of terminating on port 443 and forwarding to port 4567.
frontend tcp-proxy
bind :443 ssl crt combined-cert-key.pem
mode tcp
default_backend bk_default
backend bk_default
mode tcp
server server1 1.2.3.4:4567
I have the following model that i drew below:
I have a number of processes running on the server. I want nginx or apache to direct the incoming clients through port 80 to one of the server processes to handle the requests. However each connection also establishes a websocket connection to the same process. This is currently initiated from the client side within javascript. At the moment for testing purposes I pass the port within the html rendered on the client. The client then takes this port and estabilishes a websocket connection to the same port that handled its request.
Moving forward to an nginx or apache envionment would it be possible not to pass the port value to the client and have nginx or apache know where it directed the incoming client and use the same port for the websocket connection?
This would have the benefit on not opening all the server ports 8000, 8001, 8002 in the diagram below to the public.
I am running a FreeSWITCH server on a public domain. I am able to make call from my browser(WebRTC with sipjs) to the FreeSWITCH server from a direct Internet connection.
I am testing it on a Firewall that allows only TCP on port 443. I am running a separate TURN server. I am trying to connect from my browser by specifying TURN server with credentials. I am unable to make it work. PeerConnection is getting closed.
FreeSWTICH server is NOT behind Firewall
Client(browser) is behind Firewall
TURN server is available
Is there any configuration I have to do either in FreeSWITCH server or in the client end(javascript) to make it work?
You need to open UDP ports, cause signalling will go via WSS and media via UDP ports:
mod_sofia to serve SIP signaling via WSS and media via SRTP/DTLS.
https://www.packtpub.com/books/content/configuring-freeswitch-webrtc
Yes, you can use a TURN server. You will have to configure it to listen on port 443 with TCP, because by default a TURN server listens on port 3478.
However, if the Firewall checks for a TLS connection (i.e. for HTTPS), you will have to configure the TURN server as a TURNS (TURN over TLS).
I have built an application called Tun2Socks GUI. It's program to make Socks proxy o be transparent.
Usually it use SSH port forward or TOR as SOCKS service, but I want it can use HTTP proxy too. So I build SOCKS5 proxy my self that connect to that HTTP proxy. It's working good with capturing HTTP request from client to be sent to HTTP Proxy.
The problem when the client send SSL request, I cannot capture the request to be forwarded. How the best method to make SSL request from SOCKS proxy through HTTP Proxy?
Schema of request transportation like here :
Client SSL request > SOCKS Proxy > HTTP Proxy > Internet
Thanks
When a client intentionally wants to establish an SSL session with a target server through a proxy, it does not establish an SSL session with the proxy itself. The client first tells the proxy to establish a connection to the target server, and THEN the client initiates an SSL session with the target server. In that situation, it is not possible for the proxy to sniff the traffic as it is encrypted, nor should it be trying to. A proxy is just a pass-through, it exchanges raw data back and forth between client and server as needed. The proxy should not care what kind of requests the client is sending, since the client tells the proxy where to connect.
If you have injected your proxy in between the client and server in such a way that the client has no knowledge that your proxy exists, the client will not know that it needs to adjust its requests to make them proxy-friendly. The client will be connected to your proxy but it will think it is connected to the target server, and thus will initiate an SSL handshake that your proxy will have to respond to. Only then will your proxy have access to the client's request data (provided the handshake is successful, such as if the client does not verify peer certificates), and can then tunnel the unencrypted data to the next proxy as needed.
Update: I just thought of another scenario that should work for both cleartext and SSL connections. Regardless of whether you are transparently redirecting the client's outbound connection to your SOCKS proxy without the client knowing about it, or the client intentionally connects to the SOCKS proxy and tells it where to go, the SOCKS proxy knows the client's target host/IP:port. The SOCKS proxy can either connect directly to the target, or it can connect to the HTTP proxy and ask it to create a tunnel to the target via the HTTP CONNECT method. If successful, the client has a viable connection to the target, and any data the client sends, SSL or otherwise, will flow as-is to the target, and vice versa. Neither the SOCKS proxy nor the HTTP proxy needs to know anything about the client's request other than the target host/IP:port. That is in the initial SOCKS request, either captured from the intercepted TCP header, or explicit from the client.