from development environment, developpers need to access redis cache.
Connection to the azure redis cache is done via socks protocol on port 6380.
Issue is due to the fact that external access to the internet is done via a proxy in our company.
If it's HTTP(S) access, in nodejs for example, we use npm package 'dotenv' where we specify 'HTTP(S)' proxy settings (example for package ms-rest azure).
But here we don't find any solutions to for proxy usage for socks access.
We use the npm package 'redis' in that case.
Anyone has a solution to for proxy usage ??
Thanks in advance Mathieu
It seems to be impossible for directly connecting to Azure Redis Cache from a client behind a proxy. The reason as below:
Redis only supports tcp connection via its protocol like telnet, it's infeasible if your proxy does not support socks.
After I searched two recommended NodeJS redis clients ioredis & node_redis, both don't support build connection via proxy.
So here are two possible solutions for your current scenario.
If your proxy supports socks, you can try to create a new redis client via change some code based on the existing redis client to support socks proxy.
Recommended for the current case. I suggest that you can create a HTTP service on Azure to handle the requests from your client behind your proxy, which can pass the parameters of HTTP requests to Azure Redis Cache and wrap the result into the HTTP responses. It's Redis over HTTP like solutious/bone.
Hope it helps.
Related
On my machine, im hosting a node server that is listening on port 5000. Before setting up a forward proxy (squid), i was able to perform a GET on https://localhost:<port>. However, after setting up a forward proxy and setting the environmental variable http_proxy=<ip addr:port>, this GET request no longer works.
The error that shows up is: tunnelling socket could not be established, statusCode=503
Some additional information:
The proxy server works as I am able to connect to the internet via it.
Performing curl instead, on the https:localhost:5000/api works.
Am using request.js for the requests, using agentOptions to specify TLS protocols & ca cert.
I am hoping to understand how the traffic is now different after i add in a proxy. From my understanding, now we have to go through a sort of TLS CONNECT / tunnelling since to the proxy first, since its a HTTPS request, before coming back to my localhost. But in the case without the proxy, how is it that its working?
Any help would be greatly appreciated. Thanks!
you must add
export no_proxy='localhost,127.0.0.1'
the https work because you don't use proxy for https , you must set https_proxy='<tour_proxy>'
I'm trying to develop a web application in nodejs. I'm using an npm package called "simple-peer" but i don't think this issue is related to that. I was able to use this package and get it working when integrating it with a laravel application using an apache server as the back end. I could access the host machine through it's IP:PORT on the network and connect a separate client to the host successfully with a peer-to-peer connection. However, I'm now trying to develop this specifically in node without an apache back end. I have my express server up and running on port 3000, I can access the index page from a remote client on the same network through IP:3000. But when I try to connect through webrtc, I get a "Connection failed" error. If I connect two different browser instances on the same localhost device, the connection succeeds.
For reference: i'm just using the copy/pasted code from this usage demo. I have the "simplepeer.min.js" included and referenced in the correct directory.
So my main questions are: is there a setting or some webRTC protocol that could be blocking the remote clients from connecting? What would I need to change to meet this requirement? Why would it work in a laravel/webpack app with apache and not with express?
If your remote clients can not get icecandidates, you need TURN server.
When WebRTC Peer behind NAT, firewall or using Cellular Network(like smartphone), P2P Connection will fail.
At that time, for fallback, TURN server will work as a relay server.
I recommend coTURN.
Here is an simple implementation of simple-peer with nodejs backend for multi-user video/audio chat. You can find the client code in /public/js/main.js. Github Project and the Demo.
And just like #JinhoJang said. You do need a turn server to pass the information. Here is a list of public stun/turn servers.
I'm using Compute Engine (GCE) to run my socket server with Socket.IO (Node.js)
It's only working with polling. When I try to use a web client I receive this error code:
WebSocket connection to 'ws://myapp-socket.appspot.com/socket.io/?EIO=3&transport=websocket&sid=Tt4uNFR2fU82zsCIAADo' failed: Unexpected response code: 400
What am I doing wrong? Is it GCE configuration problem?
You cannot use the myapp-socket.appspot.com domain in your script when using WebSockets. Instead, you will need to use the external ip of the GCE instance and connect directly to that, opening any firewall ports you may be using.
I believe traffic going to the appspot.com domain is also going through frontend webservers and socket.io needs a direct connection to the server.
The Virtual Machines in Google Compute Engine have port 80 for http and port 443 for https. Using these ports for web-sockets solved the issue.
I create a new Azure Redis Cache, which take almost 5 minutes to finish creating. I'm using the node-redis package, here's my code
var client = redis.createClient(
process.env.REDIS_PORT || 6379,
process.env.REDIS_HOST || '127.0.0.1'
);
if(process.env.REDIS_HOST) {
client.auth(process.env.REDIS_KEY);
}
Yes those environment variables are properly set, it just hang on for a while and raise an error: Redis connection to mycache.redis.cache.windows.net:6380 failed - read ECONNRESET.
Now, when I use the redis-cli to try to connect with redis-cli -h myhost -p 6380 -a the-auth-key it just hang at the command line and no connection seems to be established, but no error either. It's just doing nothing. If I change the port etc, I get connection error. So I'm currently wondering what I'm doing wrong?
I've created another redis cache on a different region an plan (I took the biggest, with 99.9 SLA etc). Still, no connection is possible.
Any help would be appreciated.
New caches only have the SSL endpoint (port 6380) enabled by default. Some clients (like redis-cli) do not support SSL. You would need to check if node-redis supports SSL. You will get erorrs if you try to connect to the SSL port with a client that doesn't support SSL.
If you need to use a client does not support SSL, there are two options. One is to create an SSL tunnel between the local machine and the Redis cache, using an application like 'stunnel'. I know stunnel works well for ad-hoc scenarios like redis-cli, but I'm not sure how it would perform under production load.
The second option is to enable the non-SSL endpoint (port 6379) in the Azure portal. However, we don't recommend this for production caches since your access key and data will all be sent in plaintext.
Is there way to set Proxy settings (route via proxy Server) for HazelcastClient to connect to remote cache server (which is behind a firwall)
Thanks
No since Hazelcast clients use an internally developed (even though open source), plain TCP protocol, there is no real proxy support. You might be able to use a SOCKS proxy though but this is not supported.
There's also a prototype to tunnel the protocol through a HTTPS session but same thing, not officially supported: https://github.com/noctarius/https-tunnel-openshift-hazelcast