Web-sockets tunnel for HTTP requests: facilitates requests to an HTTP server sitting behind a firewall.
WStunnel creates an HTTPS tunnel that can connect servers sitting behind an HTTP proxy and firewall to clients on the internet. It differs from many other projects by handling many concurrent tunnels allowing a central client (or set of clients) to make requests to many servers sitting behind firewalls. Each client/server pair are joined through a rendez-vous token.
At the application level the situation is as follows, an HTTP client wants to make request to an HTTP server behind a firewall and the ingress is blocked by a firewall:
HTTP-client ===> ||firewall|| ===> HTTP-server
The WStunnel app implements a tunnel through the firewall. The assumption is that the WStunnel client app running on the HTTP-server box can make outbound HTTPS requests. In the end there are 4 components running on 3 servers involved:
the http-client application on a client box initiates HTTP requests
the http-server application on a server box behind a firewall handles the HTTP requests
the WStunnel server application on a 3rd box near the http-client intercepts the http-client's requests in order to tunnel them through (it acts as a surrogate "server" to the http-client)
the WStunnel client application on the server box hands the http requests to the local http-server app (it acts as a "client" to the http-server) The result looks something like this:
But this is not the full picture. Many WStunnel clients can connect to the same server and many http-clients can make requests. The rendez-vous between these is made using secret tokens that are registered by the WStunnel client. The steps are as follows:
WStunnel client is initialized with a token, which typically is a sizeable random string, and the hostname of the WStunnel server to connect to
WStunnel client connects to the WStunnel server using WSS or HTTPS and verifies the hostname-certificate match
WStunnel client announces its token to the WStunnel server
HTTP-client makes an HTTP request to WStunnel server with a std URI and a header containing the secret token
WStunnel server forwards the request through the tunnel to WStunnel client
WStunnel client receives the request and issues the request to the local server
WStunnel client receives the HTTP reqponse and forwards that back through the tunnel, where WStunnel server receives it and hands it back to HTTP-client on the still-open original HTTP request
In addition to the above functionality, wstunnel does some queuing in order to handle situations where the tunnel is momentarily not open. However, during such queing any HTTP connections to the HTTP-server/client remain open, i.e., they are not made aware of the queueing happening.
The implementation of the actual tunnel is intended to support two methods (but only the first is currently implemented). The preferred high performance method is websockets: the WStunnel client opens a secure websockets connection to WStunnel server using the HTTP CONNECT proxy traversal connection upgrade if necessary and the two ends use this connection as a persistent bi-directional tunnel. The second (Not yet implemented!) lower performance method is to use HTTPS long-poll where the WStunnel client makes requests to the server to shuffle data back and forth in the request and response bodies of these requests.
Getting Started
You will want to have 3 machines handy (although you could run everything on one machine to try it out):
www.example.com will be behind a firewall running a simple web site on port 80
wstun.example.com will be outside the firewall running the tunnel server
client.example.com will be outside the firewall wanting to make HTTP requests to www.example.com through the tunnel
The above example tells WStunnel client to only forward requests to http://localhost. It is possible to allow the wstunnel to target multiple hosts too. For this purpose the original HTTP client must pass an X-Host header to name the host and WStunnel client must be configured with a regexp that limits the destination web server hostnames it allows. For example, to allow access to *.some.example.com over https use:
Note the use of -server and -regexp, this is because the server named in -server is used when there is no X-Host header. The host in the -server option does not have to match the regexp but it is recommended for it match.
Using a Proxy
WStunnel client may use a proxy as long as that proxy supports HTTPS CONNECT. Basic authentication may be used if the username and password are embedded in the url. For example, -proxy http://myuser:mypass@proxy-server.com:3128. In addition, the command line client will also respect the https_proxy/http_proxy environment variables if they're set. As websocket connections are very long lived, please set read timeouts on your proxy as high as possible.
Using Secure Web Sockets (SSL)
WStunnel does not support SSL natively (although that would not be a big change). The recommended approach for using WSS (web sockets through SSL) is to use nginx, which uses the well-hardened openssl library, whereas WStunnel would be using the non-hardened Go SSL implementation. In order to connect to a secure tunnel server from WStunnel client use the wss URL scheme, e.g. wss://wstun.example.com. Here is a sample nginx configuration:
server { listen 443; server_name wstunnel.test.rightscale.com;
ssl_certificate <path to crt>; ssl_certificate_key <path to key>;
#configure ssl ssl on; ssl_protocols SSLv3 TLSv1; ssl_ciphers HIGH:!ADH; ssl_prefer_server_ciphers on; # don't trust the client # caches 10 MB of SSL sessions in memory, faster than OpenSSL's cache: ssl_session_cache shared:SSL:10m; # cache the SSL sessions for 5 minutes, just as long as today's browsers ssl_session_timeout 5m;
Most of the time when you are using a public network, you are behind some kind of firewall or proxy. One of their purpose is to constrain you to only use certain kind of protocols. Nowadays, the most widespread protocol is http and is de facto allowed by third party equipment. This tool understands this fact and uses the websocket protocol which is compatible with http in order to bypass firewalls and proxies. Wstunnel allows you to tunnel what ever traffic you want. My inspiration came from this project but as I don't want to install npm and nodejs to use this tool, I remade it in Haskell and improved it. What to expect:
Good error messages and debug informations
Static tunneling (TCP and UDP)
Dynamic tunneling (socks5 proxy)
Support for http proxy (when behind one)
Support for tls/https server (with embeded self signed certificate, see comment in the example section)
Standalone binary for linux x86_64 (so just cp it where you want)
Standalone archive for windows
Binaries P.S: Please do not pay attention to Main.hs because as I hate to write command line code this file is crappy
Command line
Use the websockets protocol to tunnel {TCP,UDP} traffic wsTunnelClient <---> wsTunnelServer <---> RemoteHost Use secure connection (wss://) to bypass proxies
wstunnel [OPTIONS] ws[s]://wstunnelServer[:port] Client options: -L --localToRemote=[BIND:]PORT:HOST:PORT Listen on local and forwards traffic from remote -D --dynamicToRemote=[BIND:]PORT Listen on local and dynamically (with socks5 proxy) forwards traffic from remote -u --udp forward UDP traffic instead of TCP -p --httpProxy=USER:PASS@HOST:PORT If set, will use this proxy to connect to the server Server options: --server Start a server that will forward traffic for you -r --restrictTo=HOST:PORT Accept traffic to be forwarded only to this service Common options: -v --verbose Print debug information -q --quiet Print only errors -h --help Display help message -V --version Print version information
Examples
Simplest one
On your remote host, start the wstunnel's server by typing this command in your terminal
wstunnel --server ws://0.0.0.0:8080
This will create a websocket server listenning on any interface on port 8080. On the client side use this command to forwards traffic trought the websocket tunnel
wstunnel -D 8888 ws://myRemoteHost:8080
This command will create a sock5 server listenning only on loopback interface on port 8888 and will forwards traffic. Ex: With firefox you can setup a proxy using this tunnel by settings in networking preferences 127.0.0.1:8888 and selecting socks5 proxy
When behind a corporate proxy
An other useful example is when you want to bypass an http proxy (a corporate proxy for example) The most reliable way to do it is to use wstunnel as described below Start your wstunnel server with tls activated
The server will listen on any interface on port 443 (https) and restrict traffic to be forwarded only to the ssh daemon. Be aware that the server will use self signed certificate with weak cryptographic algorithm. It was made in order to add the least possible overhead while still being compliant with tls. So do not rely on wstunnel to protect your privacy, if you want to do so, forwards only traffic that is already secure by design (ex: https) Now on the client side start the client with
It will start a tcp server on port 9999 that will contact the corporate proxy, negociate a tls connection with the remote host and forward traffic to the ssh daemon on the remote host. You can now access your server from your local machine on ssh by using
（由Using Secure Web Sockets (SSL)开始的那段内容）来设置wss,即加密的ws链接来使得
gfw无法侦测传输的内容，从而顺利翻墙）：
Using Secure Web Sockets (SSL)
WStunnel does not support SSL natively (although that would not be a big change). The recommended approach for using WSS (web sockets through SSL) is to use nginx, which uses the well-hardened openssl library, whereas WStunnel would be using the non-hardened Go SSL implementation. In order to connect to a secure tunnel server from WStunnel client use the wss URL scheme, e.g. wss://wstun.example.com. Here is a sample nginx configuration:
server { listen 443; server_name wstunnel.test.rightscale.com;
ssl_certificate <path to crt>; ssl_certificate_key <path to key>;
#configure ssl ssl on; ssl_protocols SSLv3 TLSv1; ssl_ciphers HIGH:!ADH; ssl_prefer_server_ciphers on; # don't trust the client # caches 10 MB of SSL sessions in memory, faster than OpenSSL's cache: ssl_session_cache shared:SSL:10m; # cache the SSL sessions for 5 minutes, just as long as today's browsers ssl_session_timeout 5m;
CocoaPods is a dependency manager for Swift and Objective-C Cocoa projects. It has over 45 thousand libraries and is used in over 3 million apps. CocoaPods can help you scale your projects elegantly.
CocoaPods is built with Ruby and is installable with the default Ruby available on OS X. We recommend you use the default ruby. Using the default Ruby install can require you to use sudo when installing gems. Further installation instructions are in the guides.
# Xcode 8 + 9 $ sudo gem install cocoapods
We also have a Mac app for CocoaPods. It only gets major releases ATM though.
我们获取到Loom的插件之后需要进行安装，我分享的就是Chrome插件的源格式.CRX文件，你可以移步到之前的文章完成Loom插件的安装：如何在Chrome浏览器里面安装Chrome插件？安装完成之后我们可以在浏览器的右上角看到Loom的图标，点击Loom的图标则会显示我们要进行登录，你可以选择Gmail或者Outlook邮箱进行登录，当然也可以选择底部的Log in with an email进入邮箱登录页面。如果你真的没有账户的话，请在登录页面选择Sign Up进行账户的注册。
