Using GitHub when your ISP does not want you to (aka NAT breaking via TOR, SSH and IPv6).
This little story is dedicated on how to get your typical developer setup to run when you are in foreign (censored or sniffed) Wi-Fi connections or when your ISP sucks so hard that you can’t reach GitHub via IPv6.
It took some while to figure all the settings out; and as a friend had the same problems with the same ISP (well, yeah…) I thought we need more documentation for that problem.
Some internet service providers like Liberty Global and its sub-carriers like Unitymedia or UPC have so-called carrier-grade NATs which means they decide what you can access in the IPv4 world. That means you have to use their IPv4 gateway to reach legacy websites that still run on IPv4. Your connection only has an IPv6 (or at least two, one with global scope).
That also means they actively can and do block typical bittorrent websites (as they say they don’t but that’s a different story with feds). From experience in the peer-to-peer world (with the lychee.js Engine) they actively block dockerhub’s API, piratebay, KAT and some other websites. Some websites of those might work, but their backends always timeout with bad gateway errors after couple minutes.
Unitmedia or Liberty Global in particular also injects TCP RST packets in your SSH connections. That means a Sweden-VPN server won’t work for github access. The delays in download times are annoying and way below 100 kB/s on a selled 200Mbit/s internet connection. #freedom #notsomuch
Reaching GitHub via IPv6 only
GitHub is still IPv4, which means it won’t work inside carrier-grade NATs without their IPv4 gateway up and passing through your connection data. This is bad and we want to be not dependent on foreign DNS servers and/or their gateways that actively block some URLs.
Also, having a proper IPv6 setup benefits in public Wi-Fis, because it allows you to connect to the internet and break out with different NAT-breaking techniques, such as pwnat.
1. Configuring TOR for IPv6 usage
The default TOR settings on most GNU/Linux distributions I have faced (mostly Arch and Debian derivates) need these two lines added inside the /etc/torrc file:
After you’ve changed the /etc/torrc file, you also have to restart the TOR service:
sudo service tor restart
2. Configuring SSH for TOR usage
The SSH config file needs a host that we can use to determine whether we want to use a local TOR SOCKS proxy or not. That means we will create a dummy host named github-tor inside the ~/.ssh/config file. If the file doesn’t exist, create it:
ProxyCommand nc -X5 -x 127.0.0.1:9050 %h %p
These settings will use netcat (nc) if we try to connect to the github-tor host via the ssh://github-tor/path URL scheme.
3. Adding remotes to your repository
In git we have remotes to access different Hosts for the same repository. We now add a remote called “tor” that uses our TOR proxied connection.
In your repository folder, add the remotes with the following scheme. The example here used the former “email@example.com:Artificial-Engineering/lycheeJS.git” remote that is defaulted for github’s plain SSH usage, so you can see the scheme differences directly:
git remote add tor ssh://github-tor/Artificial-Engineering/lycheeJS.git
Now you can go to your repository and simply pull from the other remote.
cd /opt/lycheejs; # The git repository
git pull tor master; # Pull from the master branch
git pull tor development; # Pull from the development branch
The ISPs here in Germany tend to inject SSL certificates, especially in public Wi-Fis. Some of their SSL certificates are cross-signed and seem to work for most hosts out there (and I still don’t know if it’s legal to use the SSL nulling bug in public, others were faced with prison for that).
So if you have something like a different SSL certificate signature via the SSH connection: DENY IT. Seriously, this is otherwise a security leak.
Always remember: The ones in control of the TOR exit nodes are the ones in control. Always be sceptical of foreign SSL certificates.