Tipos de NAT y configuración en Cisco
Existen básicamente tres modos de funcionamiento de NAT que son los que explicaré a continuación.
NAT estático
Consiste básicamente en un tipo de NAT en el cuál se mapea una dirección IP privada con una dirección IP pública de forma estática. De esta manera, cada equipo en la red privada debe tener su correspondiente IP pública asignada para poder acceder a Internet. La principal desventaja de este esquema es que por cada equipo que se desee tenga acceso a Internet se debe contratar una IP pública. Además, es posible que haya direcciones IP públicas sin usar (porque los equipos que las tienen asignadas están apagados, por ejemplo), mientras que hay equipos que no puedan tener acceso a Internet (porque no tienen ninguna IP pública mapeada). Para configurar este tipo de NAT en Cisco nos valemos de los siguientes comandos, donde se ve que el equipo con IP 192.168.1.6 conectado por medio de la interfaz fastEthernet 0/0 será nateado con la IP pública 200.41.58.112 por medio de la interfaz de salida serial 0/0.
Router(config)# ip nat inside source static 192.168.1.6 200.41.58.112 Router(config)# interface fastEthernet 0/0 Router(config-if)# ip nat inside Router(config)# interface serial 0/0 Router(config-if)# ip nat outside
NAT dinámico
Este tipo de NAT pretende mejorar varios aspectos del NAT estático dado que utiliza un pool de IPs públicas para un pool de IPs privadas que serán mapeadas de forma dinámica y a demanda. La ventaja de este esquema es que si se tienen por ejemplo 5 IPs públicas y 10 máquinas en la red privada, las primeras 5 máquinas en conectarse tendrán acceso a Internet. Si suponemos que no más de 5 máquinas estarán encendidas de forma simultánea nos garantiza que todas las máquinas de nuestra red privada tendrán salida a Internet eventualmente. Para configurar este tipo de NAT definimos el pool de IPs públicas disponibles y el rango de direcciones privadas que deseamos que sean nateadas.
En el siguiente ejemplo se cuenta con las direcciones IPs públicas desde la 163.10.90.2 a la 163.10.90.6 y la subred privada 192.168.1.0/24.
Router(config)# ip nat pool name DIR_NAT_GLOB 163.10.90.2 163.10.90.6 netmask 255.255.255.240 Router(config)# access-list 10 permit 192.168.1.0 0.0.0.255 Router(config)# ip nat inside source list 10 pool DIR_NAT_GLOB Router(config)# interface fastEthernet 0/0 Router(config-if)# ip nat inside Router(config)# interface serial 0/0 Router(config-if)# ip nat outside
NAT con sobrecarga
El caso de NAT con sobrecarga o PAT (Port Address Translation) es el más común de todos y el más usado en los hogares. Consiste en utilizar una única dirección IP pública para mapear múltiples direcciones IPs privadas. Las ventajas que brinda tienen dos enfoques: por un lado, el cliente necesita contratar una sola dirección IP pública para que las máquinas de su red tengan acceso a Internet, lo que supone un importante ahorro económico; por otro lado se ahorra un número importante de IPs públicas, lo que demora el agotamiento de las mismas.
La pregunta casi obvia es cómo puede ser que con una única dirección IP pública se mapeen múltiples IPs privadas. Bien, como su nombre lo indica, PAT hace uso de múltiples puertos para manejar las conexiones de cada host interno. Veamos esto con el siguiente ejemplo:
La PCA quiere acceder a www.netstorming.com.ar. El socket está formado por:
- IP origen: PCA.
- Puerto origen: X.
- IP destino: www.netstorming.com.ar.
- Puerto destino: 80.
Al llegar el requierimiento anterior al router que hace PAT, el mismo modifica dicha información por la siguiente:
- IP origen: router.
- Puerto origen: Y.
- IP destino: www.netstorming.com.ar.
- Puerto destino: 80.
Además, el router arma una tabla que le permite saber a qué máquina de la red interna debe dirigir la respuesta. De esta manera, cuando recibe un segmente desde el puerto 80 de www.netstorming.com.ar dirigido al puerto Y del router, este sabe que debe redirigir dicha información al puerto X de la PCA.
La forma de configurar NAT con sobrecarga es la siguiente.
Router(config)# access-list 10 permit ip 192.168.1.0 0.0.0.255 Router(config)# ip nat inside source list 10 interface serial 0/0 overload Router(config)# interface fastEthernet 0/0 Router(config-if)# ip nat inside Router(config)# interface serial 0/0 Router(config-if)# ip nat outside
Instalación de Lighttpd
Debido a que recientemente instalé lighttpd en mi servidor con CentOS decidí compartir la documentación de lo realizado con los lectores de NetStorming, dado que quizá pueda servirles. Es muy probable que varias de las cosas que dejo debajo se puedan hacer de una manera mejor debido a que reitero que recién estoy conociendo el producto. En tal caso será bienvenido cualquier comentario y/o consejo.
Entorno
Básicamente en el servidor tengo tres blogs con WordPress y diferentes dominios. Además, cada dominio tiene en algunos casos más de un nombre que lo identifica. Los dominios en cuestión son:
- netstorming.com.ar
- mikroways.net
- leandroditommaso.com.ar
Instalación de Lighttpd
Para instalar Lighttpd en CentOS es necesario tener habilitado el repositorio de RPMForge. Luego, simplemente se invoca a yum con los siguientes paquetes:
yum install lighttpd.i386 lighttpd-fastcgi.i386 lighttpd-mod_mysql_vhost.i386
Configuración
El archivo de configuración del servidor se encuentra en /etc/lighttpd/lighttpd.conf. Al principio de dicho archivo se definen los módulos a habilitar. Por defecto no viene casi ningún módulo habilitado por lo cuál debemos elegir los que utilizaremos. En mi caso:
server.modules = (
"mod_rewrite",
"mod_redirect",
"mod_access",
"mod_fastcgi",
"mod_simple_vhost",
"mod_cgi",
"mod_accesslog" )
En la configuración anterior se puede ver que se habilitaron los módulos de FastCGI y CGI. Luego, es necesario descomentar las siguientes líneas para que funcione.
fastcgi.server = ( ".php" =>
( "localhost" =>
(
"socket" => "/var/run/lighttpd/php-fastcgi.socket",
"bin-path" => "/usr/bin/php-cgi"
)
)
)
cgi.assign = ( ".pl" => "/usr/bin/perl",
".cgi" => "/usr/bin/perl" )
Ahora bien, para utilizar FastCGI con PHP es necesario crear el directorio donde se ubicará el socket junto con el archivo del mismo y luego darle los permisos al usuario que ejecuta lighttpd, que por defecto es lighttpd.
mkdir /var/run/lighttpd touch /var/run/lighttpd/php-fastcgi.socket-0 chown -R lighttpd:lighttpd /var/run/lighttpd
Luego es necesario definir los diferentes hosts virtuales. En mi caso:
$HTTP["host"] == "^www\.mikroways\.(net|com.ar|com)" {
server.document-root = "/var/www/mikroways/"
server.name = "www.mikroways.net"
}
$HTTP["host"] =~ "(leandroditommaso.com.ar|www.leandroditommaso.com.ar|ditommaso.com.ar|www.ditommaso.com.ar)" {
server.document-root = "/var/www/leandroditommaso/"
server.name = "leandroditommaso.com.ar"
}
$HTTP["host"] =~ "www.netstorming.com.ar" {
server.document-root = "/var/www/netstorming/"
server.name = "www.netstorming.com.ar"
}
Como WordPress ejecutado con Apache se vale de un archivo .htaccess para realizar algunas reescrituras necesarias para su funcionamiento que no funcionan con Lighttpd es necesario incluir dichas reescrituras en el lenguaje del servidor web. Las cláusulas que dejo debajo pueden ponerse una única vez de forma general o múltiples veces dentro de la configuración de cada host virtual.
url.rewrite = ( "^/(wp-.+).*/?" => "$0", "^/(sitemap.xml)" => "$0", "^/(xmlrpc.php)" => "$0", "^/(.+)/?$" => "/index.php/$1" )
Prueba y retoques finales
Para verificar el funcionamiento de lo realizado es necesario reiniciar el servicio:
service lighttpd restart
Luego, configurarlo para que arranque al inicio:
chkconfig --level 35 lighttpd on
Conclusión
Con lo hecho en este post ya se puede tener un servidor con Lighttpd funcionando con soporte para PHP, hosts virtuales y el módulo de reescritura. Y todo con muy pocos y sencillos pasos. En un próximo post, luego de investigar un poco más, trataré el tema de las redirecciones, mejorando algunas cosas de la configuración anterior.
Configuración básica de DHCP en Cisco
En un post anterior he explicado en qué consiste el protocolo DHCP. En esta oportunidad la intención es mostrar la configuración de DHCP básico en un router Cisco.
Se asume un router conectado a un switch al que además se conectan dos PCs. Se le indicará al router que brinde direcciones IP de la red 192.168.10.0/24, les indique a los hosts que la ruta por defecto es la 192.168.10.1 y que no asigne la 192.168.10.10, dado que utilizaremos dicha IP para un servidor.
Router(config)# ip dhcp pool LAN_pool Router(dhcp-config)# network 192.168.10.0 255.255.255.0 Router(dhcp-config)# default-router 192.168.10.1 Router(dhcp-config)# dns-server 192.168.10.2 Router(dhcp-config)# exit Router(config)# ip dhcp excluded-address 192.168.10.1 192.168.10.10
Ahora bien, para asegurarse que el DHCP está funcionando correctamente es posible consultar las direcciones IP asignadas con el siguiente comando:
Router# show ip dhcp binding
IP address Client-ID/ Lease expiration Type
Hardware address
192.168.10.2 0060.472D.E92B -- Automatic
192.168.10.3 00E0.8F03.BC37 -- Automatic
PPP con autenticación CHAP en Cisco
En este post explicaré cómo utilizar CHAP en PPP para realizar la autenticación. La configuración la llevaré a cabo con la CLI de Cisco. Recomiendo leer antes el post que explica el proceso de autenticación chap donde se detalla cómo se lleva a cabo este tipo de autenticación y el que explica cómo configurar PPP en un equipo Cisco, ya que se continúa con la topología y los comandos descriptos en él (lógicamente, sin la configuración de PAP).
Configuración CHAP
LaPlata# configure terminal LaPlata(config)# username BuenosAires password 1234 LaPlata(config)# interface serial 0/0/0 LaPlata(config-if)# ppp authentication chap
BuenosAires# configure terminal BuenosAires(config)# username LaPlata password 1234
Los comandos anteriores nos dejan ante el siguiente escenario:
- La autenticación es unidireccional, donde LaPlata es el autenticador y BuenosAires el autenticante.
- El nombre de usuario que se define en un equipo debe coincidir con el hostname del equipo que autenticará contra él.
- La contraseña debe ser la misma en ambos equipos.
Para lograr una autenticación bidireccional sólo basta con agregar la línea ppp authentication chap a la interfaz serial 0/0/0 en BuenosAires.
BuenosAires# configure terminal BuenosAires(config)# interface serial 0/0/0 BuenosAires(config-if)# ppp authentication chap
Configuración de PPP y PAP en Cisco
Uno de los protocolos de WAN más utilizados en la actualidad es PPP por ser un estándar abierto y porque tiene muchas características avanzadas que lo convierten en un protocolo muy interesante. En este post explicaré cómo configurarlo en un router Cisco sin autenticación y luego agregándole autenticación PAP en un sentido y en dos sentidos.
Para ello utilizaré una topología extremadamente simple, con dos routers conectados directamente a través de un enlace serial.
NOTA: si intentan hacerlo en el Packet Tracer o en un laboratorio deberán tener en cuenta que uno de los equipos (el que tenga el extremo DCE) debe tener configurado su clock rate. Puede consultarse un post anterior que explica la configuración básica de un router Cisco.
Configuración de PPP
LaPlata# configure terminal LaPlata(config)# interface serial 0/0/0 LaPlata(config-if)# ip address 192.168.1.1 255.255.255.252 LaPlata(config-if)# encapsulation ppp LaPlata(config-if)# no shutdown
BuenosAires# configure terminal BuenosAires(config)# interface serial 0/0/0 BuenosAires(config-if)# ip address 192.168.1.2 255.255.255.252 BuenosAires(config-if)# encapsulation ppp BuenosAires(config-if)# no shutdown
Como verán, configurar PPP en un router Cisco es extremadamente sencillo. De hecho, sólo es necesario cambiar la encapsulación de HDLC (encapsulación que dichos equipos traen por defecto) por PPP. Resulta apenas más difícil agregar autenticación con PAP a este enlace.
Autenticación con PAP
En este caso es necesario tener en cuenta que PAP acepta dos casos:
- Unidireccional: un equipo autentica al otro y con eso se establece el enlace. En este caso, uno de los dos routers envía su usuario y contraseña y el otro espera recibirlo. Este último verifica los datos recibidos con los que espera: si coinciden se establece el enlace, de lo contrario se lo rechaza.
- Bidireccional: es simplemente realizar dos autenticaciones unidireccionales, una para cada equipo.
A continuación se muestra cómo configurar PPP con autenticación PAP unidireccional, siendo LaPlata el autenticador. Se asume que PPP ya está configurado, tal como se mostró en la sección anterior.
LaPlata# configure terminal LaPlata(config)# username BSAS password 1234 LaPlata(config)# interface serial 0/0/0 LaPlata(config-if)# ppp authentication pap
BuenosAires# configure terminal BuenosAires(config)# interface serial 0/0/0 BuenosAires(config-if)# ppp pap sent-username BSAS password 1234
Ahora bien, configurar la autenticación bidireccional es trivial. Sólo es necesario indicarle ahora a BuenosAires que requiere autenticación PAP y el nombre de usuario y contraseña que utilizará el otro extremo; de la misma manera, se le debe indicar a LaPlata el nombre de usuario y contraseña que tiene que enviar.
BuenosAires# configure terminal BuenosAires(config)# username LaPlata password 3456 BuenosAires(config)# interface serial 0/0/0 BuenosAires(config-if)# ppp authentication pap
LaPlata# configure terminal LaPlata(config)# interface serial 0/0/0 LaPlata(config-if)# ppp pap sent-username LaPlata password 3456
Resumen
Con lo visto se puede configurar PPP con autenticación PAP unidireccional y bidireccional en equipos Cisco. En un próximo post explicaré cómo realizar la autenticación con CHAP.
