Para quienes trabajamos en sistemas brindando servicios, muchas veces nos sucede que necesitamos conectarnos a un servidor en la red de nuestros clientes, pero lamentablemente no tienen VPN (Red Privada Virtual) ni otro mecanismo para conectarnos de forma remota.
Normalmente existen alternativas:
1) Seguir insistiendo en que nos den acceso a la red mediante VPN , o bien ofrecerles configurar una. Con tiempo veré de postear un tutorial del OpenVPN.
2) Poco probable, pero he visto empresas que publican directamente el servidor en Internet, sin filtros. Recuerdo alguna vez las estadísticas de cuantos minutos podía estar un servidor Windows en Internet sin ser "hackeado" o infectado por algún tipo de virus o gusano de internet. No lo recomiendo ni un poquito
3) Programa de control remoto a alguna PC. Recomiendo TeamViewer. No siempre es posible obtener este tipo de acceso. http://www.teamviewer.com
4) Solicitar que abran el puerto de SSH en su conexión externa (Internet) para poder entrar creando túneles. Esta alternativa es bastante simple de usar, y existen diferentes formas de sacar provecho:
a) Si el acceso lo necesitamos a 1 sólo servidor , podemos redirigir el puerto, usando tuneles "locales". Esto permitirá transferir de forma lógica ese puerto hacia nuestro equipo desde donde nos conectamos.
Ejemplo con PuTTY:
* Configuramos una sesión, apuntando a la IP pública del servidor (si no tiene una IP fija podemos usar NO-IP o DynDNS para localizar su IP cambiante), e indicamos el puerto
* Vamos a la pestaña SSH y al expandirla seleccionamos Tunnels, y configuramos un tunnel de la siguiente manera
Seleccionamos
Source Port: el puerto a redirigir. En este ejemplo el 23 (TELNET)
Destination: La IP del servidor seguido del puerto. Puede ser el mismo equipo donde apuntamos o a otro que sea visible desde el servidor de SSH
Local: Esto indica que el puerto remoto será transferido al puerto local. Esto permitirá que podamos conectarnos en la direccion 127.0.0.1 (localhost ) al puerto que indicamos en Source Port como si fuera el equipo remoto.
Add : debemos presionar el botón para agregar el puerto. Podemos repetirlo para diferentes puertos de diferentes equipos.
Es importante destacar 2 cosas:
a) No todos los servicios soportan "tunneling". Algunos servicios necesitan ser accedidos por VPN o estando en la red local
b) Si tenemos varios equipos a los cuales acceder en el mismo puerto, podemos elegir diferentes puertos locales en "Source Port). Sólo deberemos cambiar el puerto para acceder a un servidor diferente
En este ejemplo estamos conectándonos al puerto 23 de un servidor remoto que es visible para el servidor que usamos para conectarnos por SSH. En este ejemplo, usamos el 23 local. La forma de conectarnos a él sería:
telnet 127.0.0.1 23
Si fuera un servidor web, pondríamos el puerto 80 y podríamos acceder de la siguiente forma
b) Si son varios servidores, dependiendo de la cantidad de equipos y puertos, podemos hacer lo mismo de arriba seleccionando un puerto local diferente para cada servidor como en el ejemplo de la imagen
o podemos crear un "proxy socks" con un único puerto
El SSH permite crear un tunel "dinámico" o proxy socks. Esto permite usar múltiples puertos a través de un único tunel, siempre que el programa lo permita.
Por ejemplo, en Firefox podemos seleccionar el proxy socks en la configuración y estaremos navegando como si nuestro equipo fuera el servidor de SSH. Esto lo haremos en Opciones->Avanzado->Red->Conexión/Configurar :
Lo mismo podemos hacer con programas como PuTTY, Filezilla (FTP), etc, que permiten seleccionar un Proxy Socks para conectarse al servidor remoto.
c) Podemos usar el mismo mecanismo que en b) , pero si nuestro programa NO soporta Proxy, o no queremos complicarnos la existencia, podemos usar Proxifier (hay un trial en la página del producto).
Proxifier permite hablar con la mayoría de los programas aunque no tengan la opción de configurar el proxy socks, de forma transparente. Permite configurar rangos de direcciones IP asociadas a un determinado proxy (podemos usar más de uno a la vez) sin tener que hacer nada en el programa.
Para mayor información, http://www.proxifier.com/
3) Usar un tunel remoto. Si nuestro cliente "no sabe como hacerle" y está perdido, pero sigue necesitando nuestra ayuda, podemos usar un Tunel Remoto. Cabe aclarar que hacer esto sin el consentimiento del cliente nos podría meter en problemas.
Un tunel remoto es similar a un tunel local, sólo que en lugar de mapear un puerto del servidor en nuestra PC/Servidor de la oficina, será el servidor del cliente quien se conectará a la PC/Servidor de la oficina para maperar su propio puerto. El resultado es similar, sólo que no seremos nostros quienes iniciemos la comunicación.
Para mayor claridad: Imaginemos que este cliente no tiene VPN ni está en las soluciones a corto plazo, que no tiene conocimiento de como abrir un puerto en el firewall para publicar el SSH o cualquier otro en Internet (no como Uds :-) o no quiere complicarse la existencia, pero sigue necesitando nuestro apoyo, podemos hacer que la montaña vaya a Mahoma.
Para esto, necesitamos tener un servidor SSH publicado en Internet, o bien nuestra PC con un servicio de SSH. Me inclino más por el servidor. Lo ideal sería que usarámos un puerto como el 443 en lugar del 22 (default) para evitar los firewalls en nuestro cliente.
Si nuestra IP no es fija, podemos usar un servicio como NO-IP o DynDNS para obtener una direccion dinámica con un nombre permanente. Muchos routers de Internet soportan DYNDNS y NO-IP de forma nativa, pero de no ser así, podemos instalar el cliente en el servidor o cualquier PC de la oficina. http://www.no-ip.com . Sólo deben crear una cuenta de usuario, descargar el cliente y listo.
Volviendo a nuestro tema original, vamos a configurar PuTTY apuntando a nuestro servidor, asumamos:
Nombre de servidor: miempresa.no-ip.biz (no-ip.com dispone de varios dominios gratuitos y otros de paga).
Puerto: 443
Nuestro servidor puede ser Linux o Unix (lo ideal), o Windows. En Windows debemos instalar OpenSSH para Windows, y es bastante simple de configurar. http://sourceforge.net/projects/sshwindows/
En el servidor del cliente, si es Windows, configuramos la conexión a esa dirección, y creamos un tunel con lo siguiente:
Esto va a crear una conexión desde el servidor del cliente hasta nuestro servidor en la oficina en el puerto 2222, apuntando al OTRO servidor, en este caso el 192.168.1.123 en el puerto 22 (defautl para SSH).
Es decir, si hacemos ssh -p 2222 usuario@127.0.0.1 no va a pedir la clave para llegar al servidor remoto dentro de la red del cliente, que no necesita estar publicado y no necesita ser el servidor que se conecta con nosotros.
Ahora, ya que podemos ver el servidor en nuestra máquina, podemos crear un proxy socks hacia el cliente.
En Windows: Creamos una conexión apuntando a 127.0.0.1 en el puerto 2222 y luego es simplemente crear un tunnel dinámico como antes
Si es en Linux la cosa se pone más simple:
ssh -p 2222 usuario@127.0.0.1 -D 8080
Si conocemos lo suficiente de scripts en Unix/Linux podremos incluso crear un tunel persistente, que se reconecte cada X tiempo.
NOTA: Deben tener acceso a Internet desde el equipo en el cliente que se conecta a sus oficinas.
NOTA2: Deben tener activado el TCP Forwarding en el servidor local (es el default)
NOTA3: Repito, deben obtener el permiso del cliente, o sentirá que se están conectando a sus espaldas.
Normalmente existen alternativas:
1) Seguir insistiendo en que nos den acceso a la red mediante VPN , o bien ofrecerles configurar una. Con tiempo veré de postear un tutorial del OpenVPN.
2) Poco probable, pero he visto empresas que publican directamente el servidor en Internet, sin filtros. Recuerdo alguna vez las estadísticas de cuantos minutos podía estar un servidor Windows en Internet sin ser "hackeado" o infectado por algún tipo de virus o gusano de internet. No lo recomiendo ni un poquito
3) Programa de control remoto a alguna PC. Recomiendo TeamViewer. No siempre es posible obtener este tipo de acceso. http://www.teamviewer.com
4) Solicitar que abran el puerto de SSH en su conexión externa (Internet) para poder entrar creando túneles. Esta alternativa es bastante simple de usar, y existen diferentes formas de sacar provecho:
a) Si el acceso lo necesitamos a 1 sólo servidor , podemos redirigir el puerto, usando tuneles "locales". Esto permitirá transferir de forma lógica ese puerto hacia nuestro equipo desde donde nos conectamos.
Ejemplo con PuTTY:
* Configuramos una sesión, apuntando a la IP pública del servidor (si no tiene una IP fija podemos usar NO-IP o DynDNS para localizar su IP cambiante), e indicamos el puerto
* Vamos a la pestaña SSH y al expandirla seleccionamos Tunnels, y configuramos un tunnel de la siguiente manera
Seleccionamos
Source Port: el puerto a redirigir. En este ejemplo el 23 (TELNET)
Destination: La IP del servidor seguido del puerto. Puede ser el mismo equipo donde apuntamos o a otro que sea visible desde el servidor de SSH
Local: Esto indica que el puerto remoto será transferido al puerto local. Esto permitirá que podamos conectarnos en la direccion 127.0.0.1 (localhost ) al puerto que indicamos en Source Port como si fuera el equipo remoto.
Add : debemos presionar el botón para agregar el puerto. Podemos repetirlo para diferentes puertos de diferentes equipos.
Es importante destacar 2 cosas:
a) No todos los servicios soportan "tunneling". Algunos servicios necesitan ser accedidos por VPN o estando en la red local
b) Si tenemos varios equipos a los cuales acceder en el mismo puerto, podemos elegir diferentes puertos locales en "Source Port). Sólo deberemos cambiar el puerto para acceder a un servidor diferente
En este ejemplo estamos conectándonos al puerto 23 de un servidor remoto que es visible para el servidor que usamos para conectarnos por SSH. En este ejemplo, usamos el 23 local. La forma de conectarnos a él sería:
telnet 127.0.0.1 23
Si fuera un servidor web, pondríamos el puerto 80 y podríamos acceder de la siguiente forma
b) Si son varios servidores, dependiendo de la cantidad de equipos y puertos, podemos hacer lo mismo de arriba seleccionando un puerto local diferente para cada servidor como en el ejemplo de la imagen
o podemos crear un "proxy socks" con un único puerto
El SSH permite crear un tunel "dinámico" o proxy socks. Esto permite usar múltiples puertos a través de un único tunel, siempre que el programa lo permita.
Por ejemplo, en Firefox podemos seleccionar el proxy socks en la configuración y estaremos navegando como si nuestro equipo fuera el servidor de SSH. Esto lo haremos en Opciones->Avanzado->Red->Conexión/Configurar :
Lo mismo podemos hacer con programas como PuTTY, Filezilla (FTP), etc, que permiten seleccionar un Proxy Socks para conectarse al servidor remoto.
c) Podemos usar el mismo mecanismo que en b) , pero si nuestro programa NO soporta Proxy, o no queremos complicarnos la existencia, podemos usar Proxifier (hay un trial en la página del producto).
Proxifier permite hablar con la mayoría de los programas aunque no tengan la opción de configurar el proxy socks, de forma transparente. Permite configurar rangos de direcciones IP asociadas a un determinado proxy (podemos usar más de uno a la vez) sin tener que hacer nada en el programa.
Para mayor información, http://www.proxifier.com/
3) Usar un tunel remoto. Si nuestro cliente "no sabe como hacerle" y está perdido, pero sigue necesitando nuestra ayuda, podemos usar un Tunel Remoto. Cabe aclarar que hacer esto sin el consentimiento del cliente nos podría meter en problemas.
Un tunel remoto es similar a un tunel local, sólo que en lugar de mapear un puerto del servidor en nuestra PC/Servidor de la oficina, será el servidor del cliente quien se conectará a la PC/Servidor de la oficina para maperar su propio puerto. El resultado es similar, sólo que no seremos nostros quienes iniciemos la comunicación.
Para mayor claridad: Imaginemos que este cliente no tiene VPN ni está en las soluciones a corto plazo, que no tiene conocimiento de como abrir un puerto en el firewall para publicar el SSH o cualquier otro en Internet (no como Uds :-) o no quiere complicarse la existencia, pero sigue necesitando nuestro apoyo, podemos hacer que la montaña vaya a Mahoma.
Para esto, necesitamos tener un servidor SSH publicado en Internet, o bien nuestra PC con un servicio de SSH. Me inclino más por el servidor. Lo ideal sería que usarámos un puerto como el 443 en lugar del 22 (default) para evitar los firewalls en nuestro cliente.
Si nuestra IP no es fija, podemos usar un servicio como NO-IP o DynDNS para obtener una direccion dinámica con un nombre permanente. Muchos routers de Internet soportan DYNDNS y NO-IP de forma nativa, pero de no ser así, podemos instalar el cliente en el servidor o cualquier PC de la oficina. http://www.no-ip.com . Sólo deben crear una cuenta de usuario, descargar el cliente y listo.
Volviendo a nuestro tema original, vamos a configurar PuTTY apuntando a nuestro servidor, asumamos:
Nombre de servidor: miempresa.no-ip.biz (no-ip.com dispone de varios dominios gratuitos y otros de paga).
Puerto: 443
Nuestro servidor puede ser Linux o Unix (lo ideal), o Windows. En Windows debemos instalar OpenSSH para Windows, y es bastante simple de configurar. http://sourceforge.net/projects/sshwindows/
En el servidor del cliente, si es Windows, configuramos la conexión a esa dirección, y creamos un tunel con lo siguiente:
Esto va a crear una conexión desde el servidor del cliente hasta nuestro servidor en la oficina en el puerto 2222, apuntando al OTRO servidor, en este caso el 192.168.1.123 en el puerto 22 (defautl para SSH).
Es decir, si hacemos ssh -p 2222 usuario@127.0.0.1 no va a pedir la clave para llegar al servidor remoto dentro de la red del cliente, que no necesita estar publicado y no necesita ser el servidor que se conecta con nosotros.
Ahora, ya que podemos ver el servidor en nuestra máquina, podemos crear un proxy socks hacia el cliente.
En Windows: Creamos una conexión apuntando a 127.0.0.1 en el puerto 2222 y luego es simplemente crear un tunnel dinámico como antes
Si es en Linux la cosa se pone más simple:
ssh -p 2222 usuario@127.0.0.1 -D 8080
Si conocemos lo suficiente de scripts en Unix/Linux podremos incluso crear un tunel persistente, que se reconecte cada X tiempo.
NOTA: Deben tener acceso a Internet desde el equipo en el cliente que se conecta a sus oficinas.
NOTA2: Deben tener activado el TCP Forwarding en el servidor local (es el default)
NOTA3: Repito, deben obtener el permiso del cliente, o sentirá que se están conectando a sus espaldas.
