Mostrando entradas con la etiqueta Redes. Mostrar todas las entradas
Mostrando entradas con la etiqueta Redes. Mostrar todas las entradas

jueves, 2 de junio de 2011

Construcción de Plugin Nagios/Centreon para inodos

En esta ocación quiero compartir con ustedes un plugin muy básico para revisar el estado de los inodos en un FileSystem remoto a nuestro servidor de monitorio Nagios vía SNMP.

Para conseguir que el agente SNMP, nos pueda regresar información de los i-nodos de su sistema se requiere autorización, eso lo hacemos con el atributo "disk" y como parámetro se me envía cada uno de los FileSystem que deseamos monitorear. Esto seria agregando por ejemplo unas lineas al archivo snmpd.conf como las que siguen:

disk /
disk /home

Ya con este cambio solo queda reiniciar el servicio. Se puede verificar con el comando snmpwalk o el plugin que tenemos, desde el servidor de monitoreo o NMS.


#!/bin/bash
#check_snmp_inodes.sh
# Argumentos:
# 1. Community
# 2. Version
# 3. IP Address
# 4. FS
# 5. warning
# 6. critical
if [ $# -eq 6 ]; then
#Se localiza el indice del FS
isExist=`snmpwalk -c $1 -v $2 $3 dsktable | grep -e "$4$" | wc -l`
if [ $isExist -eq 1 ]; then
index=`snmpwalk -c $1 -v $2 $3 dsktable | grep -e "$4$" | awk 'BEGIN{FS="."}{print $2}' | awk '{print $1}'`
uso=`snmpwalk -c $1 -v $2 $3 .1.3.6.1.4.1.2021.9.1.10.$index | awk '{print $4}'`
valor=""
#Menor que
if [ $uso -lt $5 ]; then
echo "I-nodos OK $4 Esta usando $uso% de sus inodos | size=100 used=$uso"
exit 0
else
if [ $uso -lt $6 ]; then
echo "I-nodos WARNING $4 Esta usando $uso% de sus inodos | size=100 used=$uso"
exit 1
else
echo "I-nodos CRITICAL $4 Esta usando $uso% de sus inodos | size=100 used=$uso"
exit 2
fi
fi
echo "I-nodos $valor: $4 Esta usando $uso% de sus inodos | size=100 used=$uso"
exit 0
else
echo "No existe el FileSystem $4"
exit 3
fi

else
echo "Error en el paso de parametros"
exit 3
fi

miércoles, 2 de junio de 2010

PackETH, Builder of RAW TCP/IP Packet

Hace algunos meses encontre en los repositorios de Ubuntu, una herramienta para la construcción de paquetes TCP/IP, el PackETH. Durante mis épocas de estudiante hacíamos pruebas personalizando paquetes con raw sockets en lenguaje C (¿que..., hay otro?). El desarrollo con raw sockets a pesar de fácil, puede ser en algún momento un poco confuso, sobre todo por los nombres de los elementos de las estructuras de datos usadas y su respectiva referencia y/o relación con el TCP/IP.
A modo de presentación de esta herramienta, se realizaron unas pruebas en una topología tan simple como la que muestra la figura anterior, una red local y un servidor de internet. En la computadora de la red local tenemos la dirección MAC 90:4C:E5:63:71:C9 y la dirección de red 192.168.1.100, los detalles pueden observar en la siguiente imagen.
Usando el PackETH, construimos un paquete ICMP, dirigido a un servidor de google. Haciendo un paréntesis, debemos saber que cuando un paquete cruza parcialmente la nube de internet y pasa por varios routers, en cada salto algunos campos se comportan de la siguiente manera:
  • MAC Origen: En cada salto cambia y es sustituida por el dispositivo que esta enviando o reenviando la trama, colocando su propia MAC Address.
  • MAC Destino: En cada salto cambia y es sustituida por el dispositivo que esta enviando o reenviando la trama, colocando la MAC Address del equipo que recibe la trama y que esta dentro de su segmento.
  • IP Origen: Solo llega a cambiar cuando salimos de alguna red local y el gateway hace un enmascaramiento, sustituyendo la IP origen que le llega por la que tiene el propio Gateway.
  • IP Destino: Nunca cambia!.
Conociendo la información anterior, seguimos con la instrucción del paquete, llenado los campos de la siguiente manera. Una vez terminado definimos la interfaz de salida, y damos clic a "Send". El paquete en ese momento es liberado en la ostil y lenta, red publica. Para verificar la entrega del paquete, podemos consultar algún sniffer, en este caso nos apoyamos de wireshark, donde podemos ver que el paquete se envía y recibe correctamente. Espero esta información puede ser de mucha ayuda para algunas personas.

martes, 18 de mayo de 2010

Un vistazo a Iptables con DMZ


Revisando el baúl de los recuerdos me encontré con algunos trabajos escolares, y me se me ocurrió que era buena idea comentar alguno de ellos. Definitivamente uno de mis favoritos es iptables, y en este ejemplo hacemos una implementación de esas reglas para una arquitectura con DMZ.

Les voy a compartir un script, que lo que hace es activar un firewall usando iptables y que a la vez tiene finalidad de ayudarnos a protegernos a nivel de capa de red y transporte. El único requerimiento es tener instalado awk, e iptables en linux.

#!/bin/bash
#Re-adaptado por:
#Martin Edmundo Barriga Orozco

#Revisamos la dependencia de AWK
awk --version > /dev/null
if [ "$?" != "0" ]; then
echo "Se requiere AWK para continuar"
exit 1
fi

echo "Preparando interfaces..."
echo 1 > /proc/sys/net/ipv4/ip_forward

#Interfaces de red que usamos para la red LAN, DMZ e Internet
if_lan="eth1"
if_dmz="eth2"
if_pub="eth0"

#Direcciones que tenemos en cada interface
ip_pub="10.27.46.145"
ip_lan="172.16.1.254"
ip_dmz="192.168.1.254"

#Direcciones IPs conocidas.
web_server="192.168.1.1"
mail_server="192.168.1.3"
dhcp_server="192.168.1.129"
dns_server="192.168.1.2"

id_lan="172.16.0.0/16"
id_dmz="192.168.1.0/24"

#Configuracion final con el usuario
read -p "Habilitar uso para DMZ [y/N]: " enable_dmz
if [ "$enable_dmz" = "y" ]; then
if [ -n "$if_dmz" ]; then
#call metodo_valida_interfaz
echo "invocamos al metodo de validacion de interfaz"
else
echo " Interfaces Disponibles:"
#Imprimimos el listado de interfaces
ifconfig -a | awk 'BEGIN{FS="[ ]+" ; RS=""} $1!~/lo/{print " " NR ") " $1}'
read -p " Nombre de la interfaz a usar: " if_dmz

#call metodo_valida_interfaz
#echo "invocamos al metodo de validacion de interfaz"

echo -n " >>IP: " ;
#Se imprime la direccion IP de la interfaz $if_dmz
ifconfig $if_dmz | grep 'inet:' | awk 'BEGIN{FS="[ ]+"} {print $3}' | awk 'BEGIN{FS=":"}{print $2}'
read -p " Desea conservar esta IP para esta interfaz [y/N]: " tmp_ans
if [ "$tmp_ans" != "y" ]; then
read -p " Nueva IP: " ip_dmz
ifconfig $if_dmz $ip_dmz
fi
fi
fi

read -p "Habilitar el modo paranoico [y/N]: " enable_paranoico_mode


echo "Aplicando reglas del firewall..."


#Borrado de las reglas aplicadas actualmente (flush)
iptables -F #flush todas las cadenas
iptables -t nat -F
iptables -X #Borra cadenas definidas por el usuario
iptables -Z

#Activamos bitacora de reenvio
iptables -t nat -A PREROUTING -j LOG
iptables -t nat -A POSTROUTING -j LOG

#Politicas por defecto (INPUT OUTPUT FORWARD)
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -t nat -P PREROUTING ACCEPT
iptables -t nat -P POSTROUTING ACCEPT

#REDIRECCIONAMIENTO A SERVIDOR WEB EN DMZ DESDE LA LAN Y RED PUBLICA
iptables -t nat -A PREROUTING -i $if_lan -s $id_lan -d $ip_lan -p tcp --dport 80 -j DNAT --to 192.168.1.1:80
iptables -t nat -A PREROUTING -i $if_pub -d $ip_pub -p tcp --dport 80 -j DNAT --to 192.168.1.1:80
#iptables -t nat -A PREROUTING -i $if_lan -s 0.0.0.0 -d 255.255.255.255 -p udp --dport 67 -j DNAT --to 192.168.1.129:67

#ABRIENDO PUERTOS PARA INPUT, OUTPUT, FORWARD: TRABAJO SUCIO PERO HAY QUE HACERLO!

#Aceptamos peticiones de ICMP para la LAN.
iptables -A INPUT -i $if_lan -s $id_lan -d $ip_lan -p icmp -j ACCEPT
iptables -A OUTPUT -o $if_lan -s $ip_lan -d $id_lan -p icmp -j ACCEPT

if [ "$enable_dmz" = "y" ]; then
#Aceptamos peticiones e ICMP para la DMZ.
iptables -A INPUT -i $if_dmz -s $id_dmz -d $ip_dmz -p icmp -j ACCEPT
iptables -A OUTPUT -o $if_dmz -s $ip_dmz -d $id_dmz -p icmp -j ACCEPT
fi

#Aceptamos peticiones ICMP desde la red publica.
iptables -A INPUT -i $if_pub -s 0/0 -p icmp --icmp-type 8 -j ACCEPT
iptables -A OUTPUT -o $if_pub -d 0/0 -p icmp --icmp-type 0 -j ACCEPT

#Aceptamos el flujo para el DNS para la LAN. REVISAR
iptables -A INPUT -i $if_lan -p udp --dport 67 -j ACCEPT
iptables -A OUTPUT -o $if_lan -p udp --sport 67 -j ACCEPT

if [ "$enable_paranoico_mode" != "y" ]; then
#Aceptamos navegar en la web. (Opcional)
iptables -A INPUT -i $if_pub -p tcp --sport 80 -j ACCEPT
iptables -A OUTPUT -o $if_pub -p tcp --dport 80 -j ACCEPT
iptables -A INPUT -i $if_pub -p tcp --sport 443 -j ACCEPT
iptables -A OUTPUT -o $if_pub -p tcp --dport 443 -j ACCEPT

#Aceptamos las peticiones de MSNP, tenemos tolerancia. xD (Opcional)
iptables -A INPUT -i $if_pub -p tcp --sport 1863 -j ACCEPT
iptables -A OUTPUT -o $if_pub -p tcp --dport 1863 -j ACCEPT
fi

#Aceptamos el flujo de DNS para la red publica. REVISAR
iptables -A INPUT -i $if_pub -p udp --sport 53 -j ACCEPT
iptables -A OUTPUT -o $if_pub -p udp --dport 53 -j ACCEPT

if [ "$enable_dmz" = "y" ]; then
#Permitimos el flujo de de comununicacion entre el WEB server de la DMZ y los clientes de la LAN
#Evitamos rafagas de paquetes syn.
iptables -A FORWARD -i $if_lan -o $if_dmz -s $id_lan -d $web_server -p tcp --dport 80 -m limit --limit 3/minute --limit-burst 3 state --state NEW,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $if_dmz -o $if_lan -s $web_server -d $id_lan -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT

#Permitimos el flujo de de comununicacion entre el DNS server de la DMZ y los clientes de la LAN
iptables -A FORWARD -i $if_lan -o $if_dmz -s $id_lan -d $dns_server -p udp --dport 53 -j ACCEPT
iptables -A FORWARD -i $if_dmz -o $if_lan -s $dns_server -d $id_lan -p udp --sport 53 -j ACCEPT

#Permitimos el flujo de de comununicacion entre el MAIL server de la DMZ y los clientes de la LAN
iptables -A FORWARD -i $if_lan -o $if_dmz -s $id_lan -d $mail_server -p tcp --dport 25 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $if_dmz -o $if_lan -s $mail_server -d $id_lan -p tcp --sport 25 -m state --state ESTABLISHED -j ACCEPT

#Permitimos el flujo de de comununicacion entre el MAIL server de la DMZ y los clientes de la LAN
iptables -A FORWARD -i $if_lan -o $if_dmz -s $id_lan -d $mail_server -p tcp --dport 110 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $if_dmz -o $if_lan -s $mail_server -d $id_lan -p tcp --sport 110 -m state --state ESTABLISHED -j ACCEPT

#Permitimos el flujo de de comununicacion entre el MAIL server de la DMZ y los clientes de la LAN
iptables -A FORWARD -i $if_lan -o $if_dmz -s $id_lan -d $mail_server -p tcp --dport 143 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $if_dmz -o $if_lan -s $mail_server -d $id_lan -p tcp --sport 143 -m state --state ESTABLISHED -j ACCEPT

#Permitimos el flujo de ICMP hacia el servidor web
iptables -A FORWARD -i $if_lan -o $if_dmz -s $id_lan -d $web_server -p icmp -j ACCEPT
iptables -A FORWARD -i $if_dmz -o $if_lan -s $web_server -d $id_lan -p icmp -j ACCEPT

#Permitimos a nuestro servidor DNS, solicitar direcciones al DNS del ITMorelia
iptables -A FORWARD -i $if_dmz -o $if_pub -s $dns_server -d 200.33.171.1 -p udp --dport 53 -j ACCEPT
iptables -A FORWARD -i $if_pub -o $if_dmz -s 200.33.171.1 -d $dns_server -p udp --sport 53 -j ACCEPT

#iptables -A FORWARD -i $if_dmz -o $if_pub -p udp --dport 53 -j ACCEPT
#iptables -A FORWARD -i $if_pub -o $if_dmz -p udp --sport 53 -j ACCEPT

#Permitimos a nuestro servidor DNS, solicitar direcciones al DNS del ITMorelia
iptables -A FORWARD -i $if_dmz -o $if_pub -s $dns_server -d 200.33.171.8 -p udp --dport 53 -j ACCEPT
iptables -A FORWARD -i $if_pub -o $if_dmz -s 200.33.171.8 -d $dns_server -p udp --sport 53 -j ACCEPT

#Permitimos exponer nuestro webserver a la red publica.
iptables -A FORWARD -i $if_pub -o $if_dmz -d $web_server -p tcp --dport 80 -m limit --limit 5/minute --limit-burst 5 -j ACCEPT
iptables -A FORWARD -i $if_dmz -o $if_pub -s $web_server -p tcp --sport 80 -j ACCEPT
else
#Sino hay DMZ permitimos a los clientes LAN consultar DNS externos
iptables -A FORWARD -i $if_lan -o $if_pub -s $id_lan -p udp --dport 53 -j ACCEPT
iptables -A FORWARD -i $if_pub -o $if_lan -d $id_lan -p udp --sport 53 -j ACCEPT
fi

#Permitimos a las personas de la LAN, navegar en la web.
iptables -A FORWARD -i $if_lan -o $if_pub -s $id_lan -p tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $if_pub -o $if_lan -d $id_lan -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT
iptables -A FORWARD -i $if_lan -o $if_pub -s 172.16.1.21 -p tcp --dport 443 -j ACCEPT ##1863 :1503 3389
iptables -A FORWARD -i $if_pub -o $if_lan -d 172.16.1.21 -p tcp --sport 443 -j ACCEPT

#Permitimos el uso del MSNP en la computadora del SysAdmin dentro de la LAN
iptables -A FORWARD -i $if_lan -o $if_pub -s 172.16.1.21 -p tcp --dport 1863 -j ACCEPT ##1863 :1503 3389
iptables -A FORWARD -i $if_pub -o $if_lan -d 172.16.1.21 -p tcp --sport 1863 -j ACCEPT
iptables -A FORWARD -i $if_lan -o $if_pub -s 172.16.1.21 -p udp --dport 1863 -j ACCEPT
iptables -A FORWARD -i $if_pub -o $if_lan -d 172.16.1.21 -p udp --sport 1863 -j ACCEPT

#ENMASCARAMIENTO DE LA RED Y LA DMZ
iptables -t nat -A POSTROUTING -o $if_pub -s $id_lan -j MASQUERADE
if [ "$enable_dmz" = "y" ]; then
iptables -t nat -A POSTROUTING -o $if_pub -s $dns_server -p udp --dport 53 -j MASQUERADE
iptables -t nat -A POSTROUTING -o $if_pub -s $id_dmz -j MASQUERADE
iptables -t nat -A POSTROUTING -o $if_dmz -s $id_lan -d $web_server -p tcp --dport 80 -j SNAT --to-source $ip_dmz
iptables -t nat -A POSTROUTING -o $if_dmz -s ! $id_lan -d $web_server -p tcp --dport 80 -j SNAT --to-source $ip_dmz
#iptables -t nat -A POSTROUTING -o $if_dmz -s 0.0.0.0 -d $dhcp_server -p udp --dport 67 -j SNAT --to-source $ip_dmz
fi

echo "Reglas aplicadas correctamente :)"

miércoles, 23 de septiembre de 2009

ISP and his DNS Mexico List

Hace unos dias he tenido un ligero problema con los DNS que me da mi ISP (en mi caso Axtel). Algunas URL no estaban siendo resueltas por dichos DNS. El caso es que resulta estresante trabajar en este contexto. Justamente trate de conseguir con opendns pero tampoco me resolvia esta y no podia accesar.
Despues de un rato recorde que tenia una lista de servidores de dominio, que algunos ISP me han asignado, en diversos momentos. Hoy solo quiero compartirlos:
AT&T
  • 85.255.115.52
  • 85.255.112.85 (*)
INFIERNITUM
  • 200.33.148.196 (*)
  • 200.33.171.8
  • 200.23.242.202 (*)
  • 200.23.242.196 (*)
  • 200.23.242.193 (*)
  • 200.23.242.201 (*)
  • 200.23.242.195 (*)
  • 200.23.242.203 (*)
AVANTEL
  • 148.240.241.9
  • 148.240.241.41
AXTEL
  • 200.52.12.131
  • 200.52.12.132
OPENDNS
  • 208.67.222.222
  • 208.67.220.220

* solo disponible para direcciones del ISP.

sábado, 13 de diciembre de 2008

Flashing: Router Linksys familia WRT54G

He visto un articulo en donde hablan de como programar el firmware de un router de este tipo. Antes de comenzar quiero aclarar que yo jamaz lo he hecho, me parecio interesante hablar del tema ya que para mi resulta de interes. Mi objetivo pricipal es esperar comentarios de personas que tengan experiencia con estos equipos y nos den su punto de vista.

La serie de estos routers son WRT54G/GL/GS, que van de menor a mayor capacidad, [mas informacion]. Con Tomato, que es un pequeño firmware de remplazo para algunos modelos de esta serie basados en Broadcom.

Algunas caracteristicas que nos ofrece son:
* Una GUI mas facil
* Nuevo monitor de ancho de banda
* Mejor control de acceso y QoS
* WSD
* Mejor control de conexiones P2P
* Ejecucion de scripts

Espero recibir comentarios, sobre todo de aquellos que tienen experiencia practica con algunas de estas herramientas.

martes, 10 de junio de 2008

Sufrido y tranquilizante 80

Base de Datos distribuidas.

Una materia mas que se termina, calificacion del proyecto final... 80. Debo reconocer que en algun momento perdi la esperanza de terminar este proyecto a tiempo, puedo decir con todo seguridad que es lo mas complejo que me ha tocado realizar hasta el dia de hoy (con mi poca experiencia en el mundo del desarrollo de software).

Con toda seguridad afirmo esto pues dentro de este ultimo se incluyen thread, socket, conectores de bd, dbms, programacion y un rato de estar detras de la computadora.

Las caractiristicas del proyecto son las siguientes:
+ Minimo de 5 tablas en la B.D.
+ Fragmentacion vertical de dos o mas tablas.
+ Minimo dos SMBD (MySQL y PosgreSQL).
+ Aplicacion Independiente, Heterogenea, para multiples S.O. (escrita en Java).
+ Tres agentes que se conecten a los 3 SMBD.
- Manejo de Replicas de datos.
- Tolerante a Fallas.

Los (+) son lo que entregamos y los (-) son las caracteristicas que nos falto entregar. La parte pesada la llevan los agentes pues son quienes se encargan de recibir las conexiones de las aplicaciones, y debera ver el modo de conseguir los datos con algun agente que los pueda tener para despues traerselos a la aplicacion.

Todo esto es muy laborioso, lo cual nos lleva a pensar en herramientas que nos ayuden a facilitar mas este tipo de desarrollos.

Ahora lo que queda es un poco de relax, tomar algo de aire, y prepararnos para lo que viene que ya no es tan complicado, esto si fue el climax y estres total.

jueves, 5 de junio de 2008

Administracion de Redes: Final Feliz

Me limitare a presentar la ultima practica, la cual tuvimos que realizar en menos de una semana:
Parte I. Realice los scripts para realizar el siguiente monitoreo, Utilizando el SQUID 45%:
1.- Crear los siguientes 6 usuarios: u1, u2, u3, u4, u5, admin
Acceso:

a) SOLO los usuarios 1 y 2 no tienen derecho a ver paginas XXX
b) SOLO los usuarios 3 y 4 pueden acceder de L-V de 9-14 y de 16-20 Hrs.
c)
El admón. No tiene restricciones.
d)
SOLO los usuarios que entren en la PC Cliente podrán descargar archivos a un máximo de 3 kbps.
e)
SOLO los usuarios que entren en la PC Servidor WEB podrán descargar archivos a un máximo de 25 kbps.
f)
SOLO los usuarios 1 y 4 no pueden descargar ningún tipo de archivo multimedia.

Instituto Tecnológico de Morelia

Parte II. Monitoreo con Syslog y logrotate

1.- Monitorear solo los paquetes que fluyan de la PC CLIENTE a Internet a sitios WEB , el administrador los revisara semanalmente y deberán contener la cadena “FLUJO LAN-INTERNET 80 DEL CLIENTE” para facilitar su identificación. 20%

2.- Crear un archivo para monitorear solo los paquetes del comando ping que fluyan de la LAN a Internet, los archivos log deberán tener un máximo aproximado de 15 KB y solo habrá como máximo 3 logs de este archivo. 20%

Instituto Tecnológico de Morelia

Parte III.- MRTG. 15%

  • Monitorear el flujo paquetes sobre el ancho de banda de los clientes LAN a servidores WEB.
  • Monitorear el numero de maquinas que tienen servicios de Internet (web, correo, dns, etc.).
  • Monitorear el flujo ancho de banda del Gateway.
En cuanto al mrtg, lo arrancamos tanto con snmp como con script, dentro del parametro "target" del mrtg.conf. Puedo decir que mrtg no es una herramienta facil de configurar, se requieren conocer algunos detalles previos a su implementacion.

Por ultimo solo queda comentar que el dns cache es el proveedor de la red local, y es el unico que tiene permiso por parte del firewall de hacer peticiones a servicios udp en el puerto 53, El web server (cherokee) esta semi-oculto a la red ya que las conexiones con el deberan realizarze a trevez del firewall, y es este ultimo quien nos redirecciona al web server.

Bueno ahora si por ultimo quiero agradecer a mis compañeros de esta practica: Veronica, Carol, Roberto y Oliver "chikis", por el tiempo dedicado a este proyecto, y sobre todo por todos estos años que hemos sido compañeros en el Tec, amigos muchas gracias, ya casi terminamos!!!.

martes, 3 de junio de 2008

Resultado2

Nuevamente los malos resultados continuan, en esta ocacion con administracion de redes. Los movimientos a realizar en esta ocacion eran trabajar con las bitacoras de linux (syslog, messages, logrotate). Actividades de control y administracion de la red usando Squid.

Finalmente estuve a cargo de el monitoreo, con Mrtg apoyandome en snmp, fue dificil, no se logro completamente pero me deja un gran aprendizaje esta herramienta y el protocolo respectivo.

A pesar de todo esto, nos vemos en nivelacion :(

viernes, 30 de mayo de 2008

Resultado1

Hola a todos.

Me encuentro aqui, son las 7:20 am, pasamos toda la madrugada y el inicio de la semana trabajando en el proyecto de base de datos ditribuidas. Los resultados de este proyecto no son los que estabamos buscando, ha sido un proyecto muy laborioso.

Detalles a tomar en cuenta la proxima vez:
  • empezar desde antes
  • analizar bien los sistemas
  • no dejar todo los ultimos dias
Problemas que surgieron
  • Como dividir hacer el mecanismo de dividir una consulta en dos, y dirigir cada una de estas a su destino corespondiente.
  • Manejo del comando que nos indica la consulta.
Finalmente, una disculpa si no escribo las cosa bien o no expreso lo que deseo expresar, he dormido tal vez unas 5 horas en los ultimos dos dias, creo que es.

PD: Nos vemos en nivelacion

miércoles, 7 de mayo de 2008

Proyecto de Redes: Dhcpd... ¿Querer ser dios?

En la Materia de "Administracion de redes", se presenta la unidad de iptables, todo funciona bien con esta herramienta, la verdad que esta super completa a nivel de capa de red y transporte.



La idea es que tenemos una DMZ (192.168.1.128/26), y dentro de ella algunos servicios que se pretende ofrecer a la red local (192.168.1.64/26). Las direcciones de las puertas de enlace se marcan en la topologia. El detalle es en cuanto al servidor Dhcpd, pretendemos dar direcciones a la red local, pero nosotros estamos en otro segmento de red distinto con direcciones distintas. Al parecer una regla para asignar direcciones es que el servidor debe estar en la red donde desea asignarlas.

El problema es el siguiente, el dhcpd tiene la ip 192.168.1.129/26, entonces podriamos dar direcciones en el rango 192.168.1.130 a la 192.168.1.190, y no es un rango usable en la red privada.

La solucion planteada en clase no es solo el uso de la reglas NAT, sino el uso de una interfaz virtual que tenga una direccion en el rango de la red local, y asignar atravez de ella. Estamos trabajando en ello. En dias posteriores anunciare los resultados.