Mikrotik firewalls have been good to me over the years and they work well for multiple purposes. Creating an OpenVPN server on the device can allow you to connect into your local network when you’re on the road or protect your traffic when you’re using untrusted networks.
n my previous articles we have seen how to build a home router being a VPN gateway based off FreeBSD or OpenBSD. In these cases, we used an external VPN provider to connect to, and route all of our encrypted traffic through it. However, while I received positive feeback, I also had legitimate questions about the trust given to the VPN provider. What if the VPN provider is not honest and is in fact logging despite stating the opposite? What if he is malicious and watch his clients traffic? The VPN provider could also be perfectly honest, but could be breached (OS vulnerability, OpenSSL/Heartbleed, Shellshock, etc...) by attackers then logging clients traffics. Or simply, may be we perfectly trust it, but we just want to be in control of the VPN server itself.
Lire Aussi: http://simonmott.co.uk/vpn-bonding
There are many ways to set up a VPN. Setting up a VPN typically requires using privileged access on all hosts involved (in order to create virtual network interfaces via TUN/TAP devices), as well as opening up additional VPN ports on any existing firewall. This is an administrative overhead. If you can configure a VPN over a commonly available SSH tunnel, it will reduce the VPN provisioning overhead.
In this tutorial, I will describe how to set up a VPN over SSH in Linux, by using a command-line tool called sshuttle.
Introduction
Sovereign is a set of Ansible playbooks that you can use to build and maintain your own personal cloud (I know I know). It’s based entirely on open source software, so you’re in control.
If you’ve never used Ansible before, you a) are in for a treat and b) might find these playbooks useful to learn from, since they show off a fair bit of what the tool can do.
Background/Motivations
I had been a paying Google Apps customer for personal and corporate use since the service was in beta. Until several weeks ago, that is. I was about to set up another Google Apps account for a new project when I stopped to consider what I would be funding with my USD $50 per user per year:
A seriously questionable privacy track record.
A dwindling commitment to open standards.
A lack of long-term commitment to products.
Development of Google+: a cynical and unimaginative Facebook ripoff that’s intruding into progressively more Google products.To each her/his own, but personally I saw little reason to continue participating in the Google ecosystem. It had been years since I last ran my own server for email and such, but it’s only gotten cheaper and easier to do so. Plus, none of the commercial alternatives I looked at provided all the services I was looking for.
Rather than writing up a long and hard-to-follow set of instructions, I decided to share my server setup in a format that you can more or less just clone, configure, and run. Ansible seemed like the most appropriate way to do that: it’s simple, straightforward, and easy to pick up.
I’ve been using this setup for about a month now and it’s been great. It’s also replaced a couple of non-Google services I used, saving me money and making me feel like I’ve got a little more privacy.
The backbone of this was inspired by this post by Drew Crawford. Unlike him, my goal is not “NSA-proofing” my email, just providing a reasonable alternative to Google Apps that isn’t wildly insecure. My view is that if the NSA or any other motivated party really wants to pwn me, they’re gonna, simple as that, no matter where I host my email.
Services Provided
What do you get if you point this thing at a VPS? All kinds of good stuff!
IMAP over SSL via Dovecot, complete with full text search provided by Solr.
SMTP over SSL via Postfix, including a nice set of DNSBLs to discard spam before it ever hits your filters.
Virtual domains for your email, backed by MySQL.
Secure on-disk storage for email and more via EncFS.
Spam fighting via DSPAM and Postgrey.
Mail server verification via OpenDKIM, so folks know you’re legit.
CalDAV and CardDAV to keep your calendars and contacts in sync, via ownCloud.
Your own private Dropbox, also via ownCloud.
Your own VPN server via OpenVPN.
An IRC bouncer via ZNC.
Monit to keep everything running smoothly (and alert you when it’s not).
Web hosting (ex: for your blog) via Apache.
Firewall management via ferm.
Intrusion prevention via fail2ban and rootkit detection via rkhunter.
Nightly backups to Tarsnap.
A bunch of nice-to-have tools like mosh and htop that make life with a server a little easier.No setup is perfect, but the general idea is to provide a bunch of useful services while being reasonably secure and low-maintenance. Set it up, SSH in every couple weeks, but mostly forget about it.
Don’t want one or more of the above services? Comment out the relevant role in site.yml. Or get more granular and comment out the associated include: directive in one of the playbooks.
La page travaux DN42 de la Fédération FDN, pour ceux que ça intéresse.
DN42 est un réseau overlay, dans lequel on utilise les mêmes protocoles que sur Internet (routage inter-AS réalisé avec BGP, DNS, whois, etc).
C'est le moyen de jouer avec des techniques qu'on met en place lorsqu'on crée un FAI
DN42 : http://dn42.net/
Ancien wiki : http://dn42.volcanis.me/initenv.1.html
Wiki : http://dn42.net/pages
OVH se prépare à lancer la phase alpha publique de son service de VPNSi le VPN d'OVH est évoqué depuis maintenant près d'un an, on semble enfin s'approcher d'une phase de test un tant soit peu concrète. En effet, après quelques mois d'essais en interne, celui-ci devrait être proposé de manière publique dans une version alpha, sans doute afin de tester l'infrastructure mise en place par le géant de l'hébergement.