Easy net with SOCKS5

Reasons for using an Internet-y hostname

As developers we are used to test our web sites and applications in the local interface. Django developers are for example familiar with this:

$ python manage.py
Performing system checks...

System check identified no issues (0 silenced).
March 22, 2016 - 12:41:45
Django version 1.9, using settings 'settings.local_alcides'
Starting development server at http://127.0.0.1:8080/
Quit the server with CONTROL-C

There are some issues however when pointing the browser to the URL http://127.0.0.1/. Mainly, that these are not the final URLs of the site when it is deployed. The change from the local interface to a true domain name makes complicated to maintain internal URLs in the project.

Common workarounds include modifying /etc/hosts, which should be done with care because it utterly confuses the whole computer. Also it requires administrative privileges.

SOCKS5 to the rescue

SOCKS5 is a proxy protocol which is normally used to access different networks. The advantage of SOCKS5 is that it it can encapsulate any TCP protocol and even UDP ones. That includes HTTP/1.1, HTTP/2, web-sockets and the secure variations of those protocols. It also happens to have no overhead beyond the first few packets which are used to setup the connection.

In ShimmerCat, we have found a new use for SOCKS5: to simulate a little network right inside your development server. This effectively solves the problem when using 127.0.0.1 as the host name in the browser, without any need to change /etc/hosts.

The downside is that a browser needs to be configured to use this proxy, but ShimmerCat's side-kick, sc-tool, also takes care of that. For example, you can invoke sc-tool chrome to get a Google Chrome window ready to connect to your development site. We describe the entire process in the Getting Started page.

Forwarding connections: the "-w" option

Often your web application is dependent of third-party services, like fonts hosted at Google Fonts, Analytics or a comments third-party service. To enable a browser which is using SOCKS5 to also connect to those third party services, just invoke ShimmerCat using the -w option. Like this:

$ shimmercat delove -w

With this option, any connections to virtual domains which are not resolved internally (because they don't exist in the configuration file), are forwarded to the Internet.

Without this option, the server won't forward connections to sites which are not resolved internally. This is useful in many situations, for example, to avoid noise in your Google Analytics account while you are developing your site.

SOCKS5 in production: internal services

We originally started using SOCKS5 just for development, that's the reason why SOCKS5 is active by default only in devlove mode.

However, we soon discovered that the reverse SOCKS5 proxy built into ShimmerCat is quite handy to access monitoring and instrumentation infrastructure with uniform names. For example, if we have a complex customer setup with a MySQL database and a PhpMyAdmin server and some Kibana instances, we make them accessible via the devlove file with some predetermined names, e.g. phpmyadmin and kibana, activate the SOCKS5 proxy via --enable-socks-5, and then expose the SOCKS5 proxy port. For enhanced security we run one separate instance of ShimmerCat for all monitoring, and we protect access to the SOCKS5 port in the firewall.