RouterMaN’s Blog

Como el título lo indica, el objetivo de este post es instalar estas 3 aplicaciones y que nos muestre las estadísticas de consumo. Normalmente si instalamos solo Dansguardian y Squid en los logs del squid vemos que las peticiones para loguearse son de la propia máquina. Lo cual es inútil para el Sarg, pues todas las estadísticas serían con localhost. Para arreglar este problema, se debe compilar el squid con el tag “–enable-follow-x-forwarded-for”. Para hacerlo simplemente seguimos los siguientes pasos:

Instalamos las dependencias del squid

apt-get build-dep squid

Descargamos las fuentes del squid

cd /usr/src/

apt-get source squid

Modificamos las opciones de compilación

vim /usr/src/squid-2.6.5/debian/rules

En este archivo, en la parte del configure (linea 141 apróx) aumentamos la opcion:

--enable-follow-x-forwarded-for \

Editamos el changelog y le ponemos una version superior

vim /usr/src/squid-2.6.5/debian/changelog

En mi caso la linea queda squid (2.6.5-7) unstable; urgency=high
(Antes era squid (2.6.5-6) unstable; urgency=high)

Ahora creamos el paquete

cd /usr/src/squid-2.6.5
dpkg-buildpackage

Instalamos los paquetes generados con dpkg -i. En nuestro caso, estos paquetes son squid y squid-common

Una vez instalado los paquetes, configuramos el archivo /etc/squid.conf. Las siguientes lineas deben estar añadidas o descomentadas

acl localhost src 127.0.0.1/255.255.255.255
acl redinterna src 10.1.0.0/255.255.0.0
acl reddmz src 192.168.214.0/255.255.255.0

follow_x_forwarded_for allow localhost
acl_uses_indirect_client on
log_uses_indirect_client on

http_access allow localhost
http_access allow redinterna
http_access allow reddmz

Con eso terminamos la configuración del squid. Ahora para el dansguardian y el Sarg los instalamos como cualquier otro paquete en debian, es decir, con apt-get. Debemos indicarle al Dansguardian que mande en la cabecera HTTP al squid, el cliente inicial, para eso activamos el parametro forwardedfor (línea 248 aproximadamente)

forwardedfor = on

Para el caso del sarg, simplemente se instala, pero debemos tener en cuenta el logrotate, que por defecto está en un día. Debemos cambiarlo para que sea una vez a la semana, así como también aumentar el tamaño máximo del access.log

Una configuración RoadWarrior es aquella en la cual se tiene una red privada con uno o varios clientes que accesarán a la red como si fueran parte de ella (arquitectura host-to-net). El presente tutorial explica como configurar correctamente el openvpn 2.0.9-4 en un Debian Etch que ya tiene configurado Shorewall. Tomé como base el tutorial de la configuración para CentOS y lo modifiqué de acuerdo a lo que yo quería.

Primero instalamos el openvpn:

apt-get install openvpn

El openvpn viene con un directorio llamado easy-rsa, que tiene scripts bastante útiles para la configuración. Este directorio lo copiamos a /etc/openvpn

cp -a /usr/share/doc/openvpn/examples/easy-rsa /etc/openvpn

Ahora nos vamos a ese directorio recién creado y ejecutamos los siguientes comandos

. vars
./clean-all
./build-ca

Con ellos lo que haremos es:
* Inicializar variables de ambiente para poder trabajar con los siguientes scripts de shell para generar las variables
* Inicializamos el directorio de las claves (borrando potenciales archivos viejos)
* build-ca: procedemos a generar el certificado CA

Nos pedirá datos sobre la organización. No poner cualquier cosa ya que las preguntas se van a repetir más adelante y debemos estar seguros de lo que habíamos escrito. En Common Name debemos poner cualquier cosa pero ponerla

Una vez creado el Certificate Authority (CA), creamos la llave del Servidor

./build-key-server servidor

En Common Name ponemos Servidor u otro nombre pero que sea diferente al anterior

Con este paso se crearon dos archivos (servidor.crt y servidor.key). Estos archivos debemos copiarlos al directorio /etc/openvpn

Ahora generamos las claves de los clientes. Debemos ejecutar los mismos para cada cliente:

./build-key cliente1

Esto genera los archivos cliente1.key (llave) y cliente1.crt (certificado)

Creamos los parámetros Diffie-Hellman:

./build-dh

Ahora todos los archivos creados menos los de los clientes deben ser copiados a /etc/openvpn/, es decir ca.crt, ca.key, server.crt, server.key y dh1024.pem

Ahora pasamos los archivos necesarios a los clientes. Estos archivos son clientex.crt, clientex.key y ca.crt, se los podemos pasar vía sftp o scp, pero siempre tratando de que sea seguro.

La configuración del servidor la ponemos en /etc/openvpn/server.conf

port 1194
proto udp
dev tun
persist-tun
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem

#Direcciones que se asignaran a los
#clientes, el server es .1
server 10.1.1.0 255.255.255.0

ifconfig-pool-persist ipp.txt

#Ruta para que los clientes alcancen la red local del server (1.0/24)
push “route 192.168.1.0 255.255.255.0″

#Para que los clientes se visualicen entre ellos
#Debe ir junto con la opción routeback en el shorewall
client-to-client

keepalive 10 120
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 4

La red local de la VPN es 192.168.1.0/24 y la red de la VPN es 10.1.1.0/24. El usuario remoto, si está detrás de un NAT debe tener una dirección local no perteneciente a la red de la VPN.

La configuración de los clientes sería así:

client
dev tun
proto udp
remote host.dominio.com
float #debido a que la IP de arriba es dinamica
resolv-retry infinite
nobind
persist-key
persist-tun
ca “D:\\Archivos de programa\\OpenVPN\\ca.crt” #Tener cuidado con el doble backslash (\\)
cert “D:\\Archivos de programa\\OpenVPN\\clientx.crt”
key “D:\\Archivos de programa\\OpenVPN\\clientx.key”
comp-lzo
verb 4

Ahora solo falta inicializar en los clientes, para ello es necesario el siguiente código:

openvpn –config “ruta_cliente.ovpn”

En este caso no son necesarios los \\, con uno solo basta.

Con las líneas de arriba se arma la VPN, ahora solo falta modificar el firewall para que esa nueva interfaz sea procesada y sus paquetes sean aceptados. Uso shorewall como frontend de iptables, y las modificaciones necesarias son las siguientes:
/etc/shorewall/zones (agregamos la nueva zona llamada road)

#ZONE TYPE OPTIONS IN OUT
# OPTIONS OPTIONS
road ipv4

/etc/shorewall/interfaces

#ZONE INTERFACE BROADCAST OPTIONS
road tun+ detect routeback

El Broadcast y las opciones se ponen siempre y cuando se pueda accesar desde la red a los usuarios de la VPN

/etc/shorewall/tunnels

#TYPE ZONE GATEWAY GATEWAY ZONE
openvpnserver:1194 net 0.0.0.0/0

openvpnserver puede ser reemplazado por openvpn, aunque no se recomienda debido a que este último no soporta a clientes detrás de un NAT.

/etc/shorewall/policy

#SOURCE DESTINATION POLICY
road loc ACCEPT

Aceptamos todo el tráfico proveniente de la VPN

Reiniciamos el shorewall e iniciamos el openvpn y todo debería funcionar.

AjaxTerm es un terminal basado en web. Está escrito en Python e implementa Ajax en el lado del cliente.

En Debian se instala como cualquier otro paquete:

# apt-get install ajaxterm

Una vez iniciado solo acepta peticiones del mismo equipo (127.0.0.1) al puerto 8022. Sin embargo, el Apache puede actuar de proxy y hacer esa petición por nosotros. Esto lo hacemos con el mod_proxy

# apt-get install libapache2-mod-proxy-html 

De todas formas para que el viaje hasta el apache sea cifrado debemos usar SSL. Para esto debemos habilitar el módulo ssl del apache, que viene por defecto pero que no está habilitado, así como también el módulo proxy

# cd /etc/apache2/mods-enable/
voip:/etc/apache2/mods-enabled# ln -s ../mods-available/ssl.load ssl.load
voip:/etc/apache2/mods-enabled# ln -s ../mods-available/proxy.load proxy.load

Existe otra forma de cargar los módulos en apache, y es con el comando a2enmod. Usamos este comando para añadir los modulos que faltan:

# a2enmod proxy_connect
# a2enmod proxy_ftp
# a2enmod proxy_http

Ahora lo que falta es crear las llaves válidas, para ello vamos a la carpeta donde estarán los certificados del apache, en este caso /etc/apache2/ssl/. Si no existiera, creamos el directorio con mkdir

 

# openssl req $@ -new -x509 -days 365 -nodes -out /etc/apache2/ssl/apache.pem -keyout /etc/apache2/ssl/apache.pem

Con esto ya hemos configurado todo lo referente a lo necesario para el apache. Ahora debemos configurar explicitamente la configuración del Host Virtual. Para esto editamos el archivo /etc/apache2/sites-available/default. Añadimos lo siguiente al final del mismo.

 

Listen 443
NameVirtualHost *:443

<VirtualHost *:443>
        ServerName voip.tumihost.net
        SSLEngine On
        SSLCertificateFile ssl/apache.pem

        # Suppresses the Via header
        ProxyVia Off
        # Do not flood the log
        #CustomLog /var/log/apache2/access.log combined env=!dontlog
        #SetEnvIf Request_URI "^/ajaxterm/u" dontlog

        ProxyRequests Off
        <Proxy *>
                Order deny,allow
                Allow from all
        </Proxy>
        ProxyPass /ajaxterm/ http://localhost:8022/
        ProxyPassReverse /ajaxterm/ http://localhost:8022/
</VirtualHost>

 Y listo!!. Ahora para entrar a la aplicación basta hacer https://servidor/ajaxterm/
Una vez dentro aceptar el certificado y ya podemos usar el ajaxterm cifrado.

He estado probando la distribución Xorcom Rapid basada en debian sarge, he quedado maravillado con el AMPortal (ahora conocido como Freepbx). Esta interfaz permite modificar el asterisk “en caliente” y muy intuitivamente, lo recomiendo para aquellos que recien se inicien en asterisk pero ya tienen experiencia en debian (para los que no, les recomiendo asterisk@home, basado en CentOS).

El procedimiento para instalar AMPortal lo pueden encontrar aquí (se supone que ya se tiene instalado un Xorcom Rapid, aunque con un debian sarge no debería fallar). Básicamente es el siguiente:

Agregamos la siguiente línea a nuestros repositorios:

deb http://rapid.dotsrc.org/ unstable/

luego actualizamos con

apt-get update

y luego para instalar AMP

apt-get dist-upgrade
apt-get install amportal

Intenté hace algún tiempo el procedimiento anterior en una debian etch sin resultados satisfactorios, cuando tenga tiempo (y otra máquina para probar) lo haré desde una debian sarge.

Muchos usuarios de speedy tienen el modem Xavi x8021r, el cual me parece uno de los más completos pero sin embargo es algo complicado, ya que si bien puedes cambiar el password y la configuración de los puertos por web. Una vez reiniciado todo se borra y queda como estaba antes;

Pues bien, el motivo de esto es que la configuración no se ha guardado en la memoria flash (memoria no volátil que es la que lee el router al iniciarse), por lo que debemos guardarlo en la memoria flash. Para hacerlo nos debemos loguear por telnet a nuestro router (si no has cambiado el usuario es admin y el passwd es admin) y luego hacer las modificaciones que quieras, incluso antes de entrar por telnet puedes haber modificado la configuración por web.

Por ejemplo, si queremos cambiar el password haremos

$passwd
Enter Old Password:
Enter New Password:
Confirm New Password:

Set Done

y para grabarlo a la flash

$commit

Set Done

Espero que esto les haya servido ya que veo que hay bastante gente que luego de reiniciar su router se pone a configurar de nuevo todo.

ACTUALIZACIÓN: También se puede hacer commit vía web; para hacerlo entramos a la subsección Commit & Reboot de la sección Admin, y luego pulsamos el botón commit. Gracias Oscar por el dato.

RoundCube es un webmail hecho con PHP y Mysql. La ventaja que tiene frente a otros webmails es que usa AJAX, lo cual lo convierte en un webmail de última generación.
RoundCube, a diferencia de otros webmails, funciona como un cliente imap, lo que le permite conectarse a cualquier servidor imap. Si lo quieres tener en tu servidor, necesitas instalar un servidor imap, en este tutorial usaremos dovecot. Existen otros servidores imap, pero su configuración es un tanto más engorrosa y ya no se podrían ver los correos con el webmail tradicional (openwebmail en mi caso) debido a que la mayoría de servidores imap almacena los correos en un directorio “Maildir” y no en los mbox a los que estamos acostumbrados.

1) Lo primero que tenemos que hacer es bajar el RoundCube y subirlo por (s)ftp a cualquier webhost (no necesariamente a la misma máquina del servidor de correo).

2) El siguiente paso a seguir es modificar los permisos de los directorios temp y log para que se puedan leer y escribir desde web. Nos posicionamos en el directorio donde subimos el RoundCube y ejecutamos:

chown -R www:www temp logs

3) Ahora pasamos a crear la BD rcm en mysql. La forma más fácil es teniendo phpmyadmin instalado, y crearlo por ahi junto con el script de inicio que se encuentra en SQL/mysql.initial.sql

4) Nos vamos al directorio config y copiamos los archivos *.php.dist a *.php

cp db.inc.php.dist db.inc.php
cp main.inc.php.dist main.inc.php

5) Editamos db.inc.php y lo modificamos dándole el nombre de usuario y la contraseña para poder ingresar a la base de datos creada en 3. Específicamente tenemos que modificar las variables:
$rcmail_config[’db_dsnw’] (acá ponemos el String de conexión a nuestra BD),
$rcmail_config[’smtp_server’] (dejar en blanco y solo modificarlo si es que prueban que el php no puede enviar correos),
$rcmail_config[’default_host’] (si está en blanco al accesar por web podremos elegir a que servidor imap conectarnos; si ponemos uno, ya no podremos elegir y solo nos conectaremos a ese),
$rcmail_config[’enable_caching’] (si nuestro webserver está en la misma PC que el mail server esta opción debe estar en FALSE.

6) Antes de accesar por web a nuestro webmail, debemos instalar previamente un servidor imap. Como dije anteriormente, usamos dovecot porque este permite seguir usando los buzones de formato mbox (queremos usar mbox para permitir compatibilidad de acceso al correo con otros webmails como por ejemplo openwebmail)

7) Estando todo listo, no queda más que ingresar por web y disfrutar de este maravilloso webmail hecho usando AJAX

holas, acá les dejo un howto de OpenVPN hecho por Iñaki de la lista de usuarios de debian en español. Gracias a Iñaki por dejar usar su howto.

Montar varias VPNs entre redes con OpenVPN
*******************************************
*******************************************

Tenemos 3 delegaciones con un router cada una:

A:
- Dominio: a.com
- Subred: 192.168.1.0/24
- Nodo VPN: 10.0.1.2

B:
- Dominio: b.com
- Subred: 192.168.2.0/24
- Nodo VPN: 10.0.2.2

C:
- Dominio: c.com
- Subred: 192.168.3.0/24
- Nodo VPN: 10.0.1.1 (para A)
- Nodo VPN: 10.0.2.1 (para B)

Vamos a conectar A con C y B con C mediante dos VPNs con OpenVPN. Todos ellos podrían tener IP dinámica. La seguridad será mediante una clave de texto plano en este caso (por simplificar).

***** En A: *****

#> apt-get install openvpn

—–/etc/openvpn/vpn_a_c.conf—–
remote c.org
float # por si c.org es IP dinámica.
port 1194
dev tun # creado por el paquete debian.
persist-tun # necesario al ejecutarse como “nobody”.
ifconfig 10.0.1.2 10.0.1.1 # nodo local - nodo remoto.
comp-lzo
ping 15
ping-restart 120
verb 3
secret /etc/openvpn/clave_a_c.txt # hay que crearla y copiarla al remoto.
persist-key # necesario al ejecutarse como “nobody”.
route 192.168.3.0 255.255.255.0 # se ruta por aquí lo que vaya a la red de C.
user nobody
group nogroup
chroot /var/empty # por seguridad.
————————————

#> modprobe tun
#> mkdir /var/empty
#> chown nobody.nogroup /var/empty
#> /etc/init.d/openvpn restart

***** En B: *****

#> apt-get install openvpn

—–/etc/openvpn/vpn_b_c.conf—–
remote c.org
float # por si c.org es IP dinámica.
port 1195 # podría ser distinto el local que el remoto pero así más sencillo.
dev tun # creado por el paquete debian.
persist-tun # necesario al ejecutarse como “nobody”.
ifconfig 10.0.2.2 10.0.2.1 # nodo local - nodo remoto.
comp-lzo
ping 15
ping-restart 120
verb 3
secret /etc/openvpn/clave_b_c.txt # hay que crearla y copiarla al remoto.
persist-key # necesario al ejecutarse como “nobody”.
route 192.168.3.0 255.255.255.0 # se ruta por aquí lo que vaya a la red de C.
user nobody
group nogroup
chroot /var/empty # por seguridad.
————————————

#> modprobe tun
#> mkdir /var/empty
#> chown nobody.nogroup /var/empty
#> /etc/init.d/openvpn restart

***** En C: *****

#> apt-get install openvpn

—–/etc/openvpn/vpn_c_a.conf—–
remote a.org
float # por si a.org es IP dinámica.
port 1194
dev-node /dev/net/tun1 # creado por el paquete debian y renombrado por nosotros.
persist-tun # necesario al ejecutarse como “nobody”.
ifconfig 10.0.1.1 10.0.1.2 # nodo local - nodo remoto.
comp-lzo
ping 15
ping-restart 120
verb 3
secret /etc/openvpn/clave_a_c.txt
persist-key # necesario al ejecutarse como “nobody”.
route 192.168.1.0 255.255.255.0 # se ruta por aquí lo que vaya a la red de A.
user nobody
group nogroup
chroot /var/empty # por seguridad.
————————————

—–/etc/openvpn/vpn_c_b.conf—–
remote b.org
float # por si b.org es IP dinámica.
port 1195 # ¡¡ojo, el 1194 está ocupado en la otra VPN con A!!
dev-node /dev/net/tun2 # creado por nosotros.
persist-tun # necesario al ejecutarse como “nobody”.
ifconfig 10.0.2.1 10.0.2.2 # nodo local - nodo remoto.
comp-lzo
ping 15
ping-restart 120
verb 3
secret /etc/openvpn/clave_b_c.txt
persist-key # necesario al ejecutarse como “nobody”.
route 192.168.2.0 255.255.255.0 # se ruta por aquí lo que vaya a la red de A.
user nobody
group nogroup
chroot /var/empty # por seguridad.
————————————

#> modprobe tun

Renombramos tun por tun1:
#> mv /dev/net/tun /dev/net/tun1

Creamos uno nuevo para la conexión con B:
#> mknod /dev/net/tun2 c 10 200

#> mkdir /var/empty
#> chown nobody.nogroup /var/empty
#> /etc/init.d/openvpn restart

***** En los iptables de A, B y C: *****

-A INPUT -i tun+ -j ACCEPT
-A OUTPUT -o tun+ -j ACCEPT
-A FORWARD -i tun+ -j ACCEPT
-A FORWARD -o tun+ -j ACCEPT

Nota: No olvidar crear los ficheros de claves que deben ser iguales entre los extremos de cada VPN:
#> openvpn –genkey –secret nombre_fichero

Y ya está, ahora deberíamos poder hacer un ping desde cualquier ordenador de A (192.168.1.0/24) a cualquiera de C (192.168.3.0/24).
Lo mismo desde B (192.168.2.0/24) a C.
Y también en sentido contrario desde C a A y desde C a B.

Si no entiendes el título del post no te preocupes, que a pesar de que suena complicado, es recontra sencillo hacerlo. Básicamente lo que hace es poder ejecutar aplicaciones gráficas de una máquina remota en tu PC local. Si has usado VNC sabes a lo que me refiero. Vamos a hacer lo mismo pero usando el servidor SSH.

Lo primero que necesitamos es configurar el servidor donde nos vamos a conectar para que acepte redireccionamiento del servidor X. Esto lo hacemos modificando en el archivo /etc/ssh/sshd_config

X11Forwarding yes

Luego reiniciamos el servidor SSH

/etc/init.d/ssh restart

Ahora pasamos al cliente. Para podernos conectar gráficamente nos valemos de la opción -X del cliente SSH. Si estamos en winbugs debemos tener nuestro servidor X local para que se comunique con el servidor X remoto. Esto lo logramos instalando Cygwin. Cuando nos pidan las aplicaciones que va a instalar instalamos xorg o xfree86 y tambien el cliente SSH.

Una vez todo listo con el comando

ssh -X usuario@maquina_remota

podremos ejecutar aplicaciones gráficas remotas

Espero les sirva este pequeño tutorial y vean que el VNC no es todo.

Holas, despues de una semana agotadora por parciales, al fin me di un tiempo para enchular a gst…
Gracias a las directivas del apache2. La enchulada consiste en crear un directorio restringido solo a algunos usuarios. Aquí un pequeño HOWTO.

Primero creamos el archivo donde va a estar guardada la contraseña del usuario que va a poder entrar al directorio restringido. Para esto usamos el comando htpasswd

htpasswd -c /home/diego/wwwpasswd usuario

y seguimos las instrucciones.

Supóngase que el directorio “restringido” que queremos que solo entren usuarios con la contraseña se encuentra en /var/www/restringido. Ahora tenemos 2 opciones: La primera es crear un archivo .htaccess y en ese archivo ponerle todas las directivas de apache que queremos para ese directorio. La otra alternativa es poner las directivas en el httpd.conf. Ojo, no hay ninguna alternativa mejor que la otra, solamente que a veces es mejor tener toda la configuración del servidor web en un solo sitio.

Si optas por usar tu archivo .htaccess este archivo deberá tener algo como esto:

AuthType Basic
AuthName “Directorio Restringido. No n00bs allowed”
AuthUserFile /home/diego/wwwpasswd
Require user usuario

Si elegimos usar el httpd.conf las mismas directivas arriba mencionadas deberán estar en una sección llamada < Directory /var/www/restringido >

Una vez seguidos estos pasos, basta reiniciar el apache2 (/etc/init.d/apache2 restart) y voila!!! ya tienes tu directorio con autenficación.

Muy pronto, más HOWTOs!!

Hola, como muchos saben, tener un servidor casero resulta muchas veces una comodidad, ya que uno facilmente podria acceder a sus archivos en su computadora remotamente, o bien facilmente montar su propio servidor web (por ejemplo uno basado en jsp ya que hasta ahora no he visto ninguno gratuito)
Hacer esto es bien sencillo, y no es necesario tener conocimientos de redes (al contrario, uno va aprendiendo mientras hace). Este es un pequeño HOWTO sobre como hacer esto. Se supone que se tiene instalado algun linux (el tutorial se hizo en una Debian Etch), aunque en windows el procedimiento es parecido.

Lo primero que hay que hacer es averiguar nuestra ip local privada si es que no la conocemos o no nos acordamos. Debemos fijarnos en el archivo /etc/network/interfaces. Nos debe salir algo parecido a esto:

devos:/home/diego# cat /etc/network/interfaces
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.1.88
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.1
# dns-* options are implemented by the resolvconf package, if installed
dns-nameservers 200.48.225.130 200.48.225.146

De este archivo obtenemos dos cosas importantes, como address encontramos nuestra direccion ip local, y como gateway encontramos la direccion del ruteador a traves del cual nos conectamos a internet.

Ahora entramos a la configuración del router. Esta parte depende del modelo del router. Hay dos formas de acceder a la configuración: Por telnet y por web. Todos soportan configuración por telnet (telneteas la ip del ruteador), pero solo en algunos se puede hacer la configuracion via web (solo basta poner la ip del ruteador en el navegador web). Para entrar te pide un usuario y/o una contraseña. En el manual del router aparecen estos dos valores (normalmente son admin y 1234). En los ruteadores antiguos, la gente de telefonica cambiaba los passwords por defecto según tu número telefónico. Por ejemplo, si tu telefono es 5468723 tu password sería 8723-1-546 (obviar las “-”, en este ejemplo el password real sería 87231546). Si con ningún método funciona, solo queda llamar al servicio técnico de speedy y pedir el password.

Una vez dentro buscamos en el menú o en algún submenú algo como “NAT Applications”. Y entramos a esta opcion. Una vez dentro, seguramente nos va a pedir una ip local y un puerto, ponemos nuestra ip local hallada y el puerto en el que funcione el servicio que queremos que sea público. Por ejemplo si tenemos un servidor ftp instalado y queremos accesar nuestra compu desde cualquier sitio abrimos el puerto 21, si queremos servidor web ponemos puerto 80 (deberemos tener instalado el apache o algun otro servidor web).

Una vez que hemos redireccionado, para acceder al servicio remotamente debemos saber nuestra ip pública. Eso lo logramos entrando a whatismyip

Como no es bonito tener que poner un ip diferente cada vez que queramos entrar podemos asignarle un nobre a nuestro servidor. Hay varios servidores gratuitos que hacen esto. Uno bueno es no-ip. Lo que hace no-ip es ir mandando nuestra dirección pública cada cierto tiempo. De esta forma en vez de poner ftp 201.183.187.26 (cambiando el numero a cada rato), podemos entrar al servicio haciendo ftp servidor.no-ip.com

Una cosa importante con respecto a esto, es que no vamos a poder acceder a nuestros servicios que queremos que sean públicos desde nuestra LAN (para nuestra LAN el ip público corresponde al router), pero si podremos acceder usando nuestra dirección ip privada dentro de la LAN. Si aún así se quiera poner el nombre que te da no-ip, recomiendo cambiar el archivo /etc/hosts poniendo la dirección que te da no-ip y en el campo de IP poner el ip privado donde se encuentre el servidor

Este es la segunda versión de este tutorial que conforme tenga tiempo lo seguiré mejorando