Ein VPN aus Einzelteilen: PPP, Tap-Devices und Netcat
Ein VPN sind zwei Aufgaben: etwas, das einen virtuellen Link macht, und etwas, das die Bytes trägt. PPP erledigt die erste seit 1994 und ist es egal, was die zweite ist — deshalb sind PPTP, L2TP und jede Wählleitung, die du je benutzt hast, dasselbe Protokoll über verschiedene Träger. Netcat ist ein Träger. Dieser Beitrag baut es auf beide Arten. Zuerst pppd: die pty-Option und was sie mit einem Pseudo-Terminal macht, die TCP-Variante, die jeder zuerst probiert, warum ein Stream-Protokoll in TCP unter Verlust zusammenbricht, die UDP-Variante, die man nehmen sollte, das asynchrone HDLC-Framing und die ACCM, die entscheidet, wie viel Bandbreite auf das Escapen von Steuerzeichen geht, Adressierung und Routing und IPV6CP, und den Link am Leben halten, wenn der Träger stirbt, ohne es zu sagen. Dann derselbe Tunnel ganz ohne PPP — ein Tap-Device, ein Datagramm pro Frame über UDP, das Längenpräfix, das man über TCP selbst erfinden muss, tun gegen tap, und Bridging. Dann der Teil, für den Netcat keine Antwort hat: den Träger in TLS wickeln mit ncat, stunnel und openssl, und in DTLS mit socat, was die Form ist, die man eigentlich will. Es ist nie wirklich das richtige Werkzeug, und das ist der Punkt: Es zeigt, wie sich Egress verhält, sobald ein Angreifer in deinem Netzwerk Root hat und der ausgehende Zugang nicht standardmäßig blockiert war, und warum Default-Deny an der Grenze die einzige Kontrolle ist, die je real war.