Skip to content

Una VPN hecha de piezas: PPP, dispositivos tap y netcat

Una VPN son dos tareas: algo que fabrica un enlace virtual y algo que transporta los bytes. PPP hace la primera desde 1994 y le da igual cuál sea la segunda — por eso PPTP, L2TP y cada línea conmutada que hayas usado son el mismo protocolo sobre portadores distintos. Netcat es un portador. Esto lo construye de las dos formas. Primero pppd: la opción pty y qué hace con un pseudoterminal, la versión TCP que todo el mundo prueba primero, por qué ejecutar un protocolo de flujo dentro de TCP se derrite bajo pérdida, la versión UDP que hay que usar, el tramado HDLC asíncrono y la ACCM que decide cuánto ancho de banda se va en escapar caracteres de control, direccionamiento y enrutado e IPV6CP, y mantener el enlace vivo cuando el portador muere sin avisar. Después el mismo túnel sin nada de PPP — un dispositivo tap, un datagrama por trama sobre UDP, el prefijo de longitud que hay que inventarse sobre TCP, tun frente a tap, y el puenteado. Después la parte para la que netcat no tiene respuesta: envolver el portador en TLS con ncat, stunnel y openssl, y en DTLS con socat, que es la forma que de verdad quieres. Nunca es la herramienta correcta, y ese es justo el asunto: enseña cómo se comporta la salida en cuanto un atacante tiene root dentro de tu red y el acceso saliente no estaba bloqueado por defecto, y por qué el default-deny en la frontera es el único control que fue real alguna vez.

14 de septiembre de 2026 · 65 min · 14226 palabras · Damien Dye

IPsec fue una buena idea. Es hora de apagarlo.

IPsec acertaba en 1995: cifrar por debajo de la aplicación, atar la asociación de seguridad a la dirección IP y que cada protocolo la herede. Luego llegó el NAT, el NAT de operador remató la faena, y la solución fue envolverlo todo en UDP y dejar un temporizador corriendo para que una tabla de traducción no te olvide. Esta entrada enseña diagrama a diagrama cómo se viene abajo — la asociación de seguridad que no sobrevive a una cabecera reescrita, los dos traductores que hoy lleva cualquier línea con CGNAT, la norma NAT64 que excluye a IPsec por su nombre, el túnel que no puede usar un segundo enlace porque ESP no tiene puertos, la MTU de la que nadie se ocupa, y L2TP y PPTP como los dos protocolos que nunca debieron estar aquí. Trae la documentación de Cisco, Juniper y Microsoft que admite cada uno de esos puntos, las dieciocho piezas que se llaman VPN IPsec incluidas dos que nunca fueron normas, por qué el Fisher-Price OS nunca ha interoperado de verdad con una pila abierta, un método utilizable para diagnosticar IPsec mientras sigas explotándolo, y el argumento para retirarlo todo con fechas.

13 de septiembre de 2026 · 72 min · 18050 palabras · Damien Dye

Ping: la herramienta de diagnóstico que abre mucho más

Ping, no el resto de ICMP, es el riesgo: el echo es un canal que todo host debe responder con tus propios bytes, así que una red que «solo permite ping» ya tiene un VPN completo hacia fuera. Esto recorre primero la amenaza — qué le cuesta a tu salida, y cómo un visitante en tu WiFi o un puerto ethernet sin bloquear puede abrir uno — luego tres túneles que funcionan construidos solo con ping (Hans, icmptunnel, y uno corto en Python con AES-128), las trampas del MTU y de IPv6, y la regla que lo cierra: descarta el echo, conserva los errores, en nftables, pf, Cisco, Junos, MikroTik y Windows.

1 de septiembre de 2026 · 38 min · 8080 palabras · Damien Dye