$./proxies

El puerto X habla con el puerto Y. Opcionalmente con TLS.

Un relé no es un producto. Es un proceso. Login: ssh user@kire.net. Haz bind donde te dijeron que puedes. El hostname de ejemplo de abajo es shell.kire.net — cámbialo desde el mail de bienvenida / el área de cliente.

Qué es esta página. Usar el shell como forward TCP, y como proxy que envuelve o termina TLS. socat, ncat, stunnel, hitch, nginx stream, haproxy — si el binario está. Si no, pregunta, o compila en $HOME. No vamos a bendecir una versión concreta en un post.

Para quién. Necesitas que el puerto X del shell hable con el puerto Y en otro sitio, o TLS delante de un servicio TCP en claro que ya corres. Si SSH -L / -D ya lo hace, deja de leer y ve a ./ssh-forwarding.

$why-a-kire-shell

IPv4 e IPv6 estables. Un PTR que no es tu cablemódem. DDoS delante. identd ya respondió. La tapa del portátil está cerrada. Esto sigue sin ser una granja de proxies residenciales, y no vamos a fingir que lo es.

$cheat-sheet

cosa	qué hace	cuándo usarlo
SSH `-L` / `-D`	túnel en la sesión que ya tienes	primer intento. suele bastar
forward TCP tonto	bytes entran, bytes salen, sin TLS	dos puertos en claro, el mismo mundo
envoltura TLS	servicio en claro + TLS por fuera	tienes un cert, el cliente espera cosas con forma de 6697
terminación TLS	TLS al entrar, en claro al salir	el backend es localhost y vago
WireGuard	overlay, no un proxy de puerto	solo si un túnel no basta. ./vpn

$for-beginners

Mira qué existe antes de compilar un altar:

command -v socat ncat stunnel nginx haproxy hitch

Los puertos privilegiados (< 1024) no son tuyos. Haz bind alto, o pregunta al staff. Los límites de procesos siguen siendo límites de procesos.

Necesito el puerto X del shell hablando con el puerto Y en otro sitio

socat, si está. Escucha en el shell, conecta más allá. Ejemplo: 9000 local → algún host en 6667. Sustituye los hosts.

socat TCP-LISTEN:9000,bind=127.0.0.1,fork,reuseaddr TCP:irc.example.net:6667

bind=127.0.0.1 significa que solo el shell puede tocarlo. Ese es el default correcto. Combínalo con SSH -L desde casa si tú necesitas tocarlo. Hacer bind público del vhost es como nacen los open proxies. No.

Necesito TLS delante de un servicio TCP en claro

stunnel (o hitch, o nginx stream) envuelve o termina. Los certs son tu problema. Un cert autofirmado vale para un cliente que controlas; no vale para desconocidos.

# stunnel.conf — TLS in front of a local plain port
foreground = no
pid = /home/user/stunnel.pid
[wrap]
accept = 127.0.0.1:6697
connect = 127.0.0.1:6667
cert = /home/user/certs/fullchain.pem
key = /home/user/certs/privkey.pem

Luego stunnel ~/stunnel.conf si el binario está. Deja la dirección de accept en loopback salvo que tengas una razón y una idea.

$for-people-who-already-know-the-flags

Un forward TCP tonto no es un proxy SSL. Uno copia bytes. El otro habla un handshake. No loguees el handshake en un archivo legible por todo el mundo. No loguees credenciales. Rota lo que loguees.

SNI: si terminas más de un nombre en un puerto, el proxy tiene que mirar el ClientHello. nginx stream + ssl_preread, haproxy ssl, mapas SNI de stunnel — elige un binario y lee su man. No vamos a redocumentar OpenSSL.

Certs de cliente: se puede. Normalmente más ceremonia de la que un shell KIRE pide. Si necesitas mTLS, ya tienes un archivo de config.

PROXY protocol: solo si el siguiente salto lo entiende. Mandarlo a un ircd stock hace un destrozo. Timeouts de idle: ponlos. Relés medio abiertos: así descubres los límites de descriptores de archivo.

SO_REUSEPORT si apilas workers. systemd --user para el proceso si te empeñas; sigue contando como un proceso. Nada de CAP_NET_BIND_SERVICE salvo que el staff lo haya dicho.

IPv4 e IPv6 existen aquí. Haz bind de la familia que querías. Un PTR de vhost no arregla mágicamente un bind malo.

Si el trabajo es «mi navegador en el Wi-Fi del café», eso es SSH -D, no esta página. Si el trabajo es «una red enrutada para la casa», eso es ./vpn y probablemente un no.

$dont

Open proxy. Relé público. «SOCKS para amigos de amigos.» El texto del sitio lo dice desde siempre.
Mining, scanners, spam, servicios que no son tuyos.
Hacer bind de 25/465/587 como MX sorpresa. No.
Loguear claves TLS completas «para debug» y dejarlas en ~/tmp.

Texto completo: AUP / TOS. Si no tienes claro si un proceso está aprobado: pregunta antes de que sea un ticket por un kill.

$smaller-tool

túnel SSH · proxy TCP/SSL · WireGuard.

área de cliente pedir un shell pregunta a un humano