DNS sobre el túnel SSH

Quiero configurar mi sistema OSX de manera que todo el tráfico de red se realice a través de un túnel SSH.

He escrito un pequeño script para este propósito, y estos son los comandos ejecutados por él:

// setup tunnel ssh -fN -D 1080 -p 22 user@remote // start up redsocks sudo redsocks -c /tmp/redsocks.conf -p /tmp/redsocks.pid // forward all tcp traffic to tunnel sudo ipfw add 0010 fwd 127.0.0.1,12345 tcp from me to any not dst-port 12345 not dst-port 1080 not dst-ip REMOTE_IP 

Yo uso redsocks para crear un proxy http a mi ssh-tunnel (para que pueda reenviar todo el tráfico tcp a través de ipfw), redsocks.conf se parece a esto:

 base { log_debug = on; log_info = on; log = "file:/tmp/redsocks.log"; redirector = generic; } redsocks { local_ip = 127.0.0.1; local_port = 55660; ip = 127.0.0.1; port = 1080; type = socks4; } 

Todo parece funcionar hasta ahora, todo el tráfico TCP en mi sistema OSX se realiza a través del túnel ssh, pero el problema es con el tráfico UDP y debido a que las consultas DNS no funcionan.

¿Cómo puedo obtener DNS en mi máquina local para trabajar a través del túnel SSH?

Tu línea ipfw … sólo reenvía el tráfico TCP. Tal vez agregar la siguiente línea?

 sudo ipfw add 0011 fwd 127.0.0.1,12345 \ udp from me \ to any not dst-port 12345 \ not dst-port 1080 \ not dst-ip REMOTE_IP 

También es una buena idea agregar set -x (para depuración) y set -e (para fallar inmediatamente si alguno de los comandos falla).

  • En general, se debe utilizar el término "tunelización SSH" para referirse a tun / tap con SSH.
  • El reenvío de puertos es una forma específica de creación de túneles, pero en este contexto sólo se debería seguir denominando "reenvío de puertos".
  • No utilice túneles SSH (como en -oTunnel y -oTunnelDevice ), excepto para trabajos ad-hoc rápidos.
    • TCP sobre TCP es una muy mala idea:
      • ¿Por qué TCP sobre TCP es una mala idea
      • Entender TCP sobre TCP: Efectos del túnel TCP en el rendimiento y la latencia de extremo a extremo
    • UDP sobre TCP agrega desmedidamente latencia a las aplicaciones que normalmente están haciendo uso de ella. Los programas que hacen uso de UDP deben tener control total sobre su propia confiabilidad y control de congestión, como es el caso de RTP.
  • DNS puede utilizar TCP como un transporte. No se restringe a UDP, aunque ése es el transporte preferido .

Además de lo que ya está utilizando, sSH permite tunelizar todo el tráfico IP, independiente del protocolo de capa 4 empleado. Su servidor remoto debe tener PermitTunnel yes y el cliente debe solicitar un túnel utilizando la directiva Tunnel . A continuación, puede utilizar ese nuevo vínculo como su puerta de enlace predeterminada. Vea las instrucciones detalladas para el túnel aquí.

¿Utiliza sshuttle en su lugar? Sshuttle afirma manejar correctamente el DNS y TCP, sin esta cantidad de juguetear – solo la opción --dns .

IME SOCKS parecía un poco viejo y no amado. Y realmente no entiendo este uso de ipfw y redsocks.

Sin embargo, quisiera señalar que SOCKS4 no soporta tunelización de DNS, así que no estoy sorprendido de que usted está teniendo problemas. Las versiones posteriores de SOCKS sí lo soportan, así que puedes ver eso. Y al parecer SSH puede apoyar SOCKS5 .