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
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
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
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
$ 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
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.
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.