sshuttle: en línea en la nube

PROGRAMA:

NOMBRE

sshuttle - documentación de sshuttle

SINOPSIS

lanzadera [opciones] [-r [nombre de usuario @] sshserver [: puerto]]subredes ...>

DESCRIPCIÓN

lanzadera le permite crear una conexión VPN desde su máquina a cualquier servidor remoto que
puede conectarse a través de ssh, siempre que ese servidor tenga Python 2.3 o superior.

Para trabajar, debe tener acceso de root en la máquina local, pero puede tener una cuenta normal
en el servidor.

Es valido correr lanzadera más de una vez simultáneamente en una sola máquina cliente,
conectarse a un servidor diferente cada vez, por lo que puede estar en más de una VPN a la vez.

Si se ejecuta en un enrutador, lanzadera puede reenviar el tráfico de toda su subred a la VPN.

OPCIONES

subredes
Una lista de subredes para enrutar a través de la VPN, con el formato abcd [/ ancho]. Válido
ejemplos son 1.2.3.4 (una sola dirección IP), 1.2.3.4/32 (equivalente a 1.2.3.4),
1.2.3.0/24 (una subred de 24 bits, es decir, con una máscara de red 255.255.255.0) y 0/0 ('solo
enrutar todo a través de la VPN ').

-yo, --listen = [ip:] puerto
Utilice esta dirección IP y número de puerto como puerto proxy transparente. Por defecto
lanzadera encuentra un puerto disponible automáticamente y escucha en IP 127.0.0.1
(localhost), por lo que no es necesario anularlo, y las conexiones solo son proxy
de la máquina local, no de máquinas externas. Si quieres aceptar
conexiones de otras máquinas en su red (es decir, para ejecutar lanzadera en un enrutador)
intente habilitar el reenvío de IP en su kernel, luego use --escucha 0.0.0.0:0.

Para el método tproxy, puede ser una dirección IPv6. Utilice esta opción dos veces si
necesario, para proporcionar direcciones IPv4 e IPv6.

-H, --hosts automáticos
Busque nombres de host remotos y actualice el local / etc / hosts archivo con coincidencia
entradas mientras la VPN esté abierta. Esto es mejor que cambiar el sistema
DNS (/ Etc / resolv.conf) ajustes, por varias razones. Primero, se agregan los nombres de host
sin nombres de dominio adjuntos, por lo que puede ssh ese servidor sin preocuparte si tu
el dominio local coincide con el remoto. Segundo, si tu lanzadera en más de uno
VPN a la vez, es imposible usar más de un servidor DNS a la vez de todos modos, pero
lanzadera se fusiona correctamente / etc / hosts entradas entre todas las copias en ejecución. Tercero, si
solo está enrutando algunas subredes a través de la VPN, probablemente prefiera mantener
usando su servidor DNS local para todo lo demás.

-NORTE, --auto-redes
Además de las subredes proporcionadas en la línea de comando, pregunte al servidor qué
subredes que cree que deberíamos enrutar y enrutarlas automáticamente. Las sugerencias
se toman automáticamente de la tabla de enrutamiento del servidor.

--DNS Capture solicitudes de DNS locales y reenvíelas al servidor DNS remoto.

--pitón
Especifique el nombre / ruta del intérprete de Python remoto. El valor predeterminado es solo
pitón, lo que significa utilizar el intérprete de Python predeterminado en el sistema remoto
SENDERO.

-r, --remote = [nombre de usuario @] sshserver [: puerto]
El nombre de host remoto y el nombre de usuario y el número de puerto ssh opcionales que se utilizarán para conectarse
al servidor remoto. Por ejemplo, example.com, [email protected],
[email protected]: 2222 o example.com:2244.

-X, --exclude = subred
Excluya explícitamente esta subred del reenvío. El formato de esta opción es el
lo mismo que el opción. Para excluir más de una subred, especifique el -x
opción más de una vez. Puedes decir algo como 0/0 -x 1.2.3.0/24 para reenviar
todo excepto la subred local a través de la VPN, por ejemplo.

-X, --excluir-de = archivo
Excluya las subredes especificadas en un archivo, una subred por línea. Útil cuando tienes
muchas subredes para excluir.

-v, --verboso
Imprime más información sobre la sesión. Esta opción se puede utilizar más de una vez.
para aumentar la verbosidad. Por defecto, lanzadera imprime solo mensajes de error.

-mi, --ssh-cmd
El comando que se utilizará para conectarse al servidor remoto. El valor predeterminado es solo ssh. Utilizar
esto si su cliente ssh se encuentra en una ubicación no estándar o si desea proporcionar más
opciones para el comando ssh, por ejemplo, -e 'ssh -v '.

- semillas-hospedadores
Una lista de nombres de host separados por comas para usar para inicializar --hosts automáticos escanear
algoritmo. --hosts automáticos hace cosas como sondear servidores SMB locales para obtener listas de
nombres de host, pero puede acelerar las cosas si usa esta opción para darle algunos nombres a
empezar desde.

- control de no latencia
Sacrifique la latencia para mejorar los puntos de referencia del ancho de banda. ssh usa un socket realmente grande
búferes, que pueden sobrecargar la conexión si comienza a realizar transferencias de archivos grandes,
haciendo que todas las demás sesiones dentro del mismo túnel vayan lentamente. Normalmente,
lanzadera trata de evitar este problema mediante un "control de llenado" que permite sólo un
cierta cantidad de datos pendientes que se almacenarán en búfer a la vez. Pero en ancho de banda alto
enlaces, esto puede dejar una gran parte de su ancho de banda infrautilizado. También hace
lanzadera parecen lentos en las pruebas comparativas de ancho de banda (las pruebas comparativas rara vez prueban la latencia del ping,
Que es que lanzadera está tratando de controlar). Esta opción desactiva la latencia
función de control, maximizando el uso de ancho de banda. Úselo bajo su propio riesgo.

-RE, --demonio
Se bifurca automáticamente en segundo plano después de conectarse al servidor remoto.
Implica --syslog.

--syslog
después de conectarse, envíe todos los mensajes de registro al syslog(3) service en lugar de stderr.
Esto está implícito si usa --demonio.

--pidfile = pidfilename
cuando se utiliza --demonio, salvar lanzaderapid para nombre de archivo pid. El valor predeterminado es
sshuttle.pid en el directorio actual.

--disable-ipv6
Si usa el método tproxy, esto deshabilitará la compatibilidad con IPv6.

- cortafuegos
(solo para uso interno) ejecute el administrador de firewall. Esta es la única parte de lanzadera
que debe ejecutarse como root. Si empiezas lanzadera como usuario no root,
ejecutar automáticamente sudo or su para iniciar el administrador de firewall, pero el núcleo de
lanzadera todavía se ejecuta como un usuario normal.

--hostwatch
(solo para uso interno) ejecute el demonio hostwatch. Este proceso se ejecuta en el lado del servidor.
y recopila nombres de host para --hosts automáticos opción. Usando esta opción por sí sola
hace que sea mucho más fácil depurar y probar el --hosts automáticos .

EJEMPLOS

Pruebe localmente mediante el proxy de todas las conexiones locales, sin usar ssh:

$ slanzadera -v 0/0

Iniciando el proxy sshuttle.
Escuchando en ('0.0.0.0', 12300).
[sudo local] Contraseña:
Administrador de firewall listo.
c: conectándose al servidor ...
s: rutas disponibles:
s: 192.168.42.0 / 24
c: conectado.
administrador de firewall: iniciando transproxy.
c: Aceptar: 192.168.42.106:50035 -> 192.168.42.121:139.
c: Aceptar: 192.168.42.121:47523 -> 77.141.99.22:443.
... etc ...
^C
administrador de firewall: deshacer cambios.
Teclado Interrumpido
c: interrupción del teclado: saliendo.
c: SW # 8: 192.168.42.121: 47523: borrando
c: SW # 6: 192.168.42.106: 50035: borrando

Pruebe la conexión a un servidor remoto, adivinando automáticamente el nombre de host y la subred:

$ sshuttle -vNHr ejemplo.org

Iniciando el proxy sshuttle.
Escuchando en ('0.0.0.0', 12300).
Administrador de firewall listo.
c: conectándose al servidor ...
s: rutas disponibles:
s: 77.141.99.0 / 24
c: conectado.
c: seed_hosts: []
administrador de firewall: iniciando transproxy.
hostwatch: Encontrado: testbox1: 1.2.3.4
hostwatch: Encontrado: mytest2: 5.6.7.8
hostwatch: Encontrado: controlador de dominio: 99.1.2.3
c: Aceptar: 192.168.42.121:60554 -> 77.141.99.22:22.
^C
administrador de firewall: deshacer cambios.
c: interrupción del teclado: saliendo.
c: SW # 6: 192.168.42.121: 60554: borrando

DISCUSIÓN

Cuando empieza lanzadera crea una sesión ssh en el servidor especificado por el -r .
If -r se omite, iniciará tanto su cliente como su servidor localmente, lo que a veces es
útil para realizar pruebas.

Después de conectarse al servidor remoto, lanzadera carga su código fuente (python) en el
extremo remoto y lo ejecuta allí. Por lo tanto, no es necesario instalar lanzadera en el control remoto
servidor, y nunca hay lanzadera conflictos de versiones entre el cliente y el servidor.

A diferencia de la mayoría de las VPN, lanzadera reenvía sesiones, no paquetes. Es decir, usa kernel
proxy transparenteiptables Redireccionar reglas en Linux) para capturar sesiones TCP salientes,
luego crea sesiones TCP completamente separadas hacia el destino original en el otro
Fin del túnel.

El reenvío a nivel de paquete (por ejemplo, usando los dispositivos tun / tap en Linux) parece elegante al principio,
pero da lugar a varios problemas, en particular el problema 'tcp sobre tcp'. El protocolo tcp
depende fundamentalmente de que los paquetes se eliminen para implementar su congestión
controlar el agoritmo; si pasa paquetes tcp a través de un túnel basado en tcp (como ssh), el
los paquetes tcp internos nunca se descartarán, por lo que el control de congestión del flujo tcp interno
estará completamente roto y el rendimiento será terrible. Por lo tanto, las VPN basadas en paquetes
(como IPsec y openvpn) no puede utilizar secuencias cifradas basadas en tcp como ssh o ssl, y
tienen que implementar su propio cifrado desde cero, lo cual es muy complejo y error
propenso.

lanzaderaLa simplicidad proviene del hecho de que puede utilizar de forma segura el ssh existente
túnel cifrado sin incurrir en una penalización de rendimiento. Lo hace dejando que el
el kernel del lado del cliente administra la secuencia tcp entrante, y el kernel del lado del servidor administra el
flujo tcp saliente; no es necesario que el control de la congestión se comparta entre los dos
flujos separados, por lo que un túnel basado en tcp está bien.

Use sshuttle en línea usando los servicios de onworks.net