As part of our IPv6 deployment we had to upgrade the firmware on our CPEs. We have a small variety of different models, but the majority of them are based on a Broadcom chipset. This firmware upgrade included all the features we needed for IPv6, the DHCPv6 client for the WAN, RA announcements on the LAN etc, but it also included other non-related IPv6 fixes and enhancements.
We spend a lot of time and effort regression testing these firmware pushes, and are generally pretty confident in it by the time we go to mass push it out via TR69. However, shortly after the firmware upgrade we started hearing complaints that this firmware had broken a very specific use case that we hadn’t obviously tested for.
IPv6 tunnels such as the 6in4 ones offered for free by Hurricane Electric. Odd, we hadn’t started the enablement of native IPv6 prefixes for these customers yet, but we did deploy it with ULA RAs enabled, could that be affecting things? We didn’t think so, but we had to investigate obviously.
Problem Statement:
6in4 tunnel client configured behind the router, inside the DMZ (not firewalled).
6in4 tunnel server on the internet, provided by Hurricane Electric.
Tunnel establishes correctly. Client gets an IPv6 prefix, can ping6 tunnel end-point as well as other v6 connected servers on the internet.
However, TCP sessions don’t establish over the tunnel.
python script setting up a transparent proxy to forward all TCP and DNS traffic through a SOCKS / SOCKS5 or HTTP(CONNECT) proxy using iptables -j REDIRECT target
This is a piece of software that lets you tunnel IPv4 data through a DNS
server. This can be usable in different situations where internet access is
firewalled, but DNS queries are allowed.
Imagine you’re developing a web application using a framework like Rails. You’ve got your development server fired up and are regularly reloading http://localhost:3000 to see your changes. All is going well until you want to integrate with some 3rd party service that needs to talk to your application. You’re not really going to deploy to staging on every change, are you?
If you have control over the router, then you can simply forward an external port to your local machine. Bu you’re obviously a cool startup hacker, so of course you’re working in a coffee shop or co-work space. You’ve got no time for outdated ideas like “offices”. What are you to do?
Il existe d'innombrables techniques pour faire coexister IPv4 et IPv6 sur l'Internet. Tellement qu'on s'y perd facilement. Ce nouveau RFC se concentre sur une catégorie particulière, les tunnels « IPv6 sur IPv4 » et fait la liste de tous les mécanismes de cette catégorie (des plus répandus aux plus exotiques), avec leurs forces et leurs faiblesses.
Ces tunnels sont dictés par la nécessité. La bonne méthode pour se connecter en IPv6 est clairement d'utiliser une connexion native. Mais on n'a pas toujours le choix. Aujourd'hui, depuis de nombreuses années, et sans doute encore pour un certain temps, il existe de nombreuses îles IPv6, séparées les unes des autres par des réseaux purement IPv4. Par exemple, vous avez loué une machine virtuelle chez un fournisseur qui est resté à l'ancien protocole (comme Numergy) mais vous voulez accéder à l'Internet IPv6. Ou bien vous avez déployé IPv6 sur votre campus mais votre opérateur réseau n'est toujours pas capable de fournir de l'IPv6 ce qui vous désespère. Dans ces deux cas, et dans plusieurs autres, vous serez sans doute obligé d'utiliser un tunnel. Un tunnel fonctionne en encapsulant les paquets d'un protocole dans ceux d'un autre protocole. Ainsi, pour transporter de l'IPv6 sur l'IPv4, le routeur d'entrée de tunnel met le paquet IPv6 à l'intérieur d'un paquet IPv4, celui-ci voyage ensuite par les mécanismes IPv4 habituels, sur un réseau qui ne connait qu'IPv4 et, à l'arrivée sur le routeur de sortie de tunnel, le paquet IPv6 est décapsulé (extrait du paquet IPv4) puis continue son chemin dans le réseau IPv6.
This is a piece of software that lets you tunnel IPv4 data through a DNS
server. This can be usable in different situations where internet access is
firewalled, but DNS queries are allowed.
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.
Transparent proxy server that works as a poor man's VPN. Forwards all TCP packets over ssh and
even DNS requests when using --dns option). Doesn't require admin privileges on the server side. Works with Linux and MacOS. Supports DNS tunneling.
====================
Un petit cas pratique en français : http://blog.uggy.org/post/2013/07/28/sshuttle-VPN-/-SSH