Un VPN en pièces détachées : PPP, tap et Netcat
Un VPN, c’est deux tâches : quelque chose qui fabrique un lien virtuel, et quelque chose qui transporte les octets. PPP fait la première depuis 1994 et se moque de la seconde — c’est pourquoi PPTP, L2TP et chaque ligne commutée que vous avez utilisée sont le même protocole sur des transporteurs différents. Netcat est un transporteur. Ce billet le construit des deux façons. D’abord pppd : l’option pty et ce qu’elle fait d’un pseudo-terminal, la version TCP que tout le monde essaie d’abord, pourquoi faire tourner un protocole de flux dans TCP s’effondre sous la perte, la version UDP qu’il faut prendre, le tramage HDLC asynchrone et l’ACCM qui décide de la bande passante dépensée à échapper des caractères de contrôle, l’adressage et le routage et IPV6CP, et garder le lien en vie quand le transporteur meurt sans le dire. Puis le même tunnel sans PPP du tout — un tap, un datagramme par trame sur UDP, le préfixe de longueur qu’il faut inventer soi-même sur TCP, tun contre tap, et le bridging. Puis la partie pour laquelle netcat n’a pas de réponse : envelopper le transporteur dans TLS avec ncat, stunnel et openssl, et dans DTLS avec socat, qui est la forme qu’on veut vraiment. Ce n’est jamais vraiment le bon outil, et c’est là le propos : il montre comment se comporte l’egress dès qu’un attaquant a root dans votre réseau et que l’accès sortant n’était pas bloqué par défaut, et pourquoi le default-deny à la frontière est le seul contrôle qui ait jamais été réel.