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

lunes, 27 de septiembre de 2010

Ejemplos de manipulacion de port forwarding utilizando NAT en routers Cisco

Situacion: 
 Tengo una granja de servidores (ejemplo Web, Mail y SSH) y tengo solo una direccion publica en mi router de borde. 

Escenario: 
    {Internet} --- {RTR con IP publica} ------- {Granja de Servidores} 
IP Publica: 11.12.13.14 
Mail Server: 192.168.1.5 Web Server: 192.168.1.4 
SSH: 192.168.1.6 
IP WAN: 11.12.13.14/30 
IP LAN: 192.168.1.1/24 
  
Solucion: 
 La solucion es configurar en el router Cisco NAT de tal manera de que al momento de recibir un paquete TCP al puerto destino correspondiente sepa a donde enviarlo. En este sentido, es necesario que el router re-envie los paquetes (port forwarding) de la siguiente manera: Paquetes destinados al IP 11.12.13.14 al puerto destino 25 lo envie al Mail Server (192.168.1.5) Paquetes destinados al IP 11.12.13.14 al puerto destino 80 lo envie al Web Server (192.168.1.4) Paquetes destinados al IP 11.12.13.14 al puerto destino 22 lo envie al SSH Server (192.168.1.6) 

Procedimiento: 
 La configuracion del router seria la siguiente: 
  ! ESTA ES LA INTERFAZ QUE DA HACIA LA GRANJA DE SERVIDORES 
interface FastEthernet0 
description Mi granja de servidores 
ip address 192.168.1.1 255.255.255.0 
ip nat inside 
! ! ESTA ES LA INTERFAZ QUE DA HACIA INTERNET 
interface Serial0 
description Hacia Internet 
ip address 11.12.13.14 255.255.255.252 
ip nat outside 
! !En la siguiente linea se indica que todo lo que apunte al IP 11.12.13.14 al puerto 80 lo envie al !servidor web 
ip nat inside source static tcp 192.168.1.4 80 11.12.13.14 80 extendable 
!En la siguiente linea se indica que todo lo que apunte al IP 11.12.13.14 al puerto 25 lo envie al !servidor mail 
ip nat inside source static tcp 192.168.1.5 25 11.12.13.14 25 extendable 
!En la siguiente linea se indica que todo lo que apunte al IP 11.12.13.14 al puerto 22 lo envie al !servidor ssh 
ip nat inside source static tcp 192.168.1.4 22 11.12.13.14 22 extendable 

Tips:
  Un dato muy interesante que es que se puede manipular el puerto. Por ejemplo, supongamos que tenemos un servidor web "escondido" podemos manejarlo con un puerto diferente al 80. Digamos que queremos que la gente desde Internet acceda a nuestro servidor Web utilizando el puerto 61234 podemos hacer lo siguiente: !El usuario desde Internet debe acceder a http://11.12.13.14:61234 ip nat inside source static tcp 192.168.1.4 80 11.12.13.14 61234 extendable Lo anterior es muy util para escoder servicios, ahorrar direcciones IP y darle seguridad a la red. Espero haya sido de tu utilidad, Suerte!

martes, 17 de agosto de 2010

Utilizar Linux como Teredo cliente

Introduccion:
Conectarse a una red IPv6 desde la casa u oficina hoy en dia es muy sencillo. Existen varias maneras y en este documento voy a explicar a instalar teredo y usarlo de manera muy sencilla y en pocos pasos.

Situacion:

Deseo utilizar mi servidor Linux como cliente Teredo para tener conectividad IPv6 en mi red IPv4 (el cual es a su vez nateada). En mi caso hice las pruebas desde un equipo Linux Mandriva 2010 y utilizando el servidor teredo de remlab.net

Solucion:
La solucion recomendada es utilizar el cliente Teredo para Linux llamada Miredo la cual es OpenSource, de distribucion gratuita es funciona muy bien.

Procedimiento:
1) Lo primeo es bajar Miredo de la pagina web en el URL: http://www.remlab.net/files/miredo/?C=N;O=D

2) Luego es necesario desempaquetarlo y compilarlo, en mi caso hice lo siguiente:
a) tar -jxvf miredo-1.2.3.tar.bz2
b) cd miredo-1.2.3
c) ./configure --without-Judy
d) make
e) make install

3) Finalmente ejecute Miredo con el comando:
/usr/local/sbin/miredo (luego de ejecutarlo espero entre 5-20 segundos para esperar que se cree la interfaz teredo y reciba su direccion ipv6)

Como comentario adicional el archivo de configuracion queda almacenado en:
/usr/local/etc/miredo/miredo.conf donde puedes cambiar el teredo server que deseas utilizar. Recomiendo que ubiques un servidor cercano a tu ubicacion geografica.

Para revisar:
La manera sencilla de revisar es haciendo por ejemplo un ping6 a ipv6.google.com.
Por otro lado, Miredo crea una interfaz logica en el sistema llamada teredo, la puedes revisar con el comando ifconfig. Por ejemplo:

ifconfig

teredo Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet6 addr: fe80::ffff:ffff:ffff/64 Scope:Link
inet6 addr: 2001:0:53aa:64c:18f6:6288:41b0:c5c8/32 Scope:Global
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1280 Metric:1
RX packets:243 errors:0 dropped:0 overruns:0 frame:0
TX packets:403 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:41816 (40.8 KiB) TX bytes:40042 (39.1 KiB)

Sobre la interfaz puedes utilizar herramientas como tcpdump o wireshark. Por ejemplo seria tcpdump -i teredo. Puedes tambien apreciar los paquetes entrantes y salientes los cuales se van a incrementar a medida que utilizar la conectividad IPv6

Por ultimo, tambien puedes revisar este post para probar tu conectividad IPv6
acostanetwork.blogspot.com/2009/04/probar-ipv6.html


Mas Informacion:
http://git.remlab.net/cgi-bin/gitweb.cgi?p=miredo.git;a=blob_plain;f=README;hb=HEAD

http://www.remlab.net/miredo/doc/miredo.8.html

lunes, 10 de mayo de 2010

Script en Bash para conseguir errores 404 dentro de un servidor Web

Escenario:
Tengo mi servidor Web Apache sobre Linux y quiero revisar los errores 404 (página no encontrada) o broken link de los usuarios que acceden a mi servidor.

Solución:
Ejecutar un script mediante el crontab cerca de la media noche que revise el archivo access_log del Apache con el contenido 404 y envie un correo a un destinatario.

Script:
#El objectivo de este script es revisar errores 404 dentro de los logs del WebServer
#para de esta manera evitar "broken links". Alejandro Acosta
#Notese que se ejecuta casi a la media noche para conseguir TODOS los errores 404 del dia
FECHA=`date +"%d/%b/%Y"`
cat /usr/local/apache/logs/access_log | grep $FECHA | grep " 404 " > /tmp/404.txt
#Entra en el if unicamente en caso de conseguir errores 404
if [ $? = "0" ]; then
echo $?
mail -s "Errores 404 encontrados" micorreo@miproveedor.com < /tmp/404.txt
fi
\rm /tmp/404.txt

Crontab:
57 23 * * * /root/scripts/check_logs.sh

jueves, 25 de marzo de 2010

Utilizando DNSTOP

Objetivo:
Utilizar correctamente DNSTOP

Software utilizado:
Distribución Mandriva
DNSTOP (http://www.rpmfind.net/linux/rpm2html/search.php?query=dnstop&submit=Search+...)

Ejecutando dnstop:
La manera de ejecutar dnstop es: comando interface. Por ejemplo

# dnstop {interface-name}
# dnstop eth0
# dnstop wlan0

Una salida tipica es:

Queries: 53 new, 391 total Thu Mar 25 13:04:37 2010

Sources Count %
--------------- --------- ------
200.xx.xx.5 137 35.0
200.xx.xx.2 46 11.8
200.xx.xx.253 24 6.1
190.xx.xx.2 21 5.4
200.xx.xx.140 18 4.6
200.xx.xx.30 12 3.1
200.xx.xx.141 11 2.8
200.xx.xx.118 10 2.6
200.xx.xx.186 10 2.6
10.xx.xx.162 8 2.0
200.xx.xx.138 8 2.0
200.xx.xx.6 6 1.5

Ahora bien, dnstop no solo genera la salida anterior sino que puede generar MUCHA más información, todo es cuestión de saberlo utilizar.
Por ejemplo, puedes ejecutar dnstop con el siguiente comando:
#dnstop -l 3 eth1

Durante la ejecución presiona el numero "1" o "2" o "3". Podrás ver hasta 3 niveles de resolución de nombres y así saber que nombres generalmente resuelven tus clientes.

Otra opción muy interesante es el tipo de query sobre el DNS Server (A, AAAA, PTR, etc). Para ello durante la ejecución presiona "t".

Opciones típicas de dnstop:

 s - Sources list
d - Destinations list
t - Query types
o - Opcodes
r - Rcodes
1 - 1st level Query Names ! - with Sources
2 - 2nd level Query Names @ - with Sources
3 - 3rd level Query Names # - with Sources
4 - 4th level Query Names $ - with Sources
5 - 5th level Query Names % - with Sources
6 - 6th level Query Names ^ - with Sources
7 - 7th level Query Names & - with Sources
8 - 8th level Query Names * - with Sources
9 - 9th level Query Names ( - with Sources
^R - Reset counters
^X - Exit

? - this

Links:
Este articulo es una traducción y adaptación de experiencia propia de: http://www.cyberciti.biz/faq/dnstop-monitor-bind-dns-server-dns-network-traffic-from-a-shell-prompt/

lunes, 22 de febrero de 2010

Realizar estudios de performance sobre un DNS Server

INTRODUCCION:

Recientemente tuve la necesidad de realizar algún estudio sobre el funcionamiento de dos servidores DNS los cuales soy responsable por su administración. Mis dudas
eran relacionadas al performance de los servidores.
En el mundo de los DNS el performance se mide de dos maneras:
* Throughput (numero de queries por segundo que el DNS Server es capaz de manejar)
* Latencia (tiempo de resolución de los queries)

En base a lo anterior uno mismo puede contruir unos scripts y apoyandonos en el comando DIG obtener gran información. Sin embargo durante mi investigación y
a través de una lista conseguí dos herramientas que pueden realizar un excelente estudio: dnsperf y resperf (http://www.nominum.com/services/measurement_tools.php)

OBJETIVO
Realizar y evaluar el performance de un DNS Server

SOFTWARE NECESARIO:
En mi caso hice todas las pruebas sobre un DNS Server en mandriva las herramientas sobre mandriva.
Software adicional: dnsperf y resperf. Se puede conseguir: http://www.nominum.com/services/measurement_tools.php
GNUplot

INSTALACION

wget ftp://ftp.nominum.com/pub/nominum/dnsperf/1.0.1.0/dnsperf-1.0.1.0-1-rhel-5-i386.tar.gz
tar -zxvf dnsperf-1.0.1.0-1-rhel-5-i386.tar.gz
cd dnsperf-1.0.1.0-1
rpm -ivh dnsperf-1.0.1.0-1.i386.rpm
urpmi gnuplot (MUY RECOMENDADO para generar unas gráficas más adelantes)

Los archivos binarios quedaran instalados en:
/usr/local/nom/bin

DOCUMENTACION:
Luego de la instalación del paquete existe una excelente documentación en formato pdf ubicada en:

/usr/local/nom/doc/dnsperf


FUNCIONAMIENTO:
En fin, basicamente lo que ambos programas hacen es tomar una enorme lista (un archivo de texto) donde existen miles de dominios separados por el tipo de query (A, AAAA, PTR, TXT, etc), lo envia a un servidor DNS (indicado por linea de comando) y luego empieza a recabar información para finalmente ofrecer un resumen de los resultados.
El archivo de texto puede ser editado, cambiado, modificado, etc por uno mismo sin inconveniente (archivo original: queryfile-example-100thousand).

EJEMPLOS:
Vamos a nombrar dos diferentes comandos con los cuales podemos hacer una evaluación. Recomiendo ampliamente leer la documentación oficial antes de proseguir. Estas herramientas consumen alto procesamiento de CPU, consumo de memoria y ancho de banda. Es muy sencillo saturar un servidor y dejarlo fuera de linea con estas herramientas. Adicionalmente hay que tener mucho cuidado con diversos firewalls que pueden encontrarse
en el medio entre el DNS Server y el cliente que ejecuta la aplicación.
Aquí van los ejemplos:

Comando 1: resperf
  • Ejemplo 1-1:
Query de 100000 consultas al DNS Server de localhost con un máximo de 100 consultas por segundo:

./resperf -s 127.0.0.1 -d queryfile-example-100thousand.orig -m 100

Ejemplo de la salida:

DNS Resolution Performance Testing Tool

Nominum Version 1.0.1.0

[Status] Sending
[Status] Waiting for more responses
^C
[root@localhost bin]# ./resperf -s 127.0.0.1 -d queryfile-example-100thousand -m 100

DNS Resolution Performance Testing Tool

Nominum Version 1.0.1.0

[Status] Sending
[Status] Waiting for more responses
[Status] Testing complete

Statistics:

Queries sent: 2999
Queries completed: 2985
Queries lost: 14
Ran for: 100.000002 seconds
Maximum throughput: 98.000000 qps
Lost at that point: 2.00%



  • Ejemplo 1-2:
Query de 100000 consultas al DNS Server de localhost con un máximo de 10 consultas por segundo pero con un reporte en una página Web:

./resperf-report -s 127.0.0.1 -d queryfile-example-100thousand.orig -m 10
Ejemplo de la página Web:




  • Ejemplo 1-3:
Query de 100000 consultas al DNS Server de localhost con un máximo de 100000 consultas por segundo pero con un reporte en una página Web:
./resperf-report -s 127.0.0.1 -d queryfile-example-100thousand.orig


Comando 2: dnsperf

Ejemplo 2-1:
Ejecutar 3 queries maximos al servidor localhost con un histograma de 20 por 10 segundos:

./dnsperf -d ../examples/dnsperf/queryfile-example-100thousand -q 3 -H 20 -l 10 -s 127.0.0.1

Salida del comando anterior:

[root@localhost bin]# ./dnsperf -d queryfile-example-100thousand -q 10 -H20 -l 10

DNS Performance Testing Tool

Nominum Version 1.0.1.0

[Status] Processing input data
[Status] Sending queries (to 127.0.0.1)
[Status] Testing complete


Statistics:

Parse input file: multiple times
Run time limit: 10 seconds
Ran through file: 144 times

Queries sent: 870 queries
Queries completed: 870 queries
Queries lost: 0 queries

Avg request size: 37 bytes
Avg response size: 161 bytes

Percentage completed: 100.00%
Percentage lost: 0.00%

Started at: Mon Feb 22 18:17:43 2010
Finished at: Mon Feb 22 18:17:53 2010
Ran for: 10.105866 seconds

Queries per second: 86.088614 qps

Latency: Min: 0.000284 s; Max: 1.121552 s; Avg: 0.111007 s; StdDev: 0.169328

Response latency distribution (total 870 responses):

Latency Success Fail |
<>= 1.000s 8 0 |#

Legend:

##### = success responses (RCODE was NOERROR or NXDOMAIN)
----- = failure responses (any other RCODE)


Ejemplo 2-2:

Ejecutar 20 queries maximos al servidor localhost con un histograma de 4 por 20 segundos con una cantidad máxima de 25 queries por segundo:
./dnsperf -d queryfile-example-100thousand -q 20 -H4 -l 20 -Q 25

Suerte, espero sea de tu utilidad

martes, 11 de agosto de 2009

Solucion caidas de llamadas de llamadas luego de transferir en Asterisk

Problema:
Luego de transferir una llamada de una extensión a otra con Asterisk la llamada se cae a los pocos segundos

Topología:






Solución:

La solución es muy sencilla y es configurar en el peer del Media Gateway la opcion canreinvite=no. Dicha opción viene por defecto en yes.
canreinvite=no fuerza al Asterisk a manejar ambos legs de la llamada y permanecer en el medio. Es decir, la comunicación del MediaGateway y del IPPhone pasarán siempre por el Asterisk. Existen otras opciones para evitar ello por ejemplo: utilizar diferentes protocolos y/o utilizar diferentes codecs entre ambos legs.

Procedimiento:
Editar /etc/asterisk/sip.conf y colocar la opción canreinvite=no en el peer. Por ejemplo:

[10.1.1.1]
context=from-internal
dtmfmode=rfc2833
host=10.1.1.1
insecure=very
type=friend
canreinvite=no


Suerte!,

miércoles, 17 de junio de 2009

Problemas con Postfix dsn= 4.4.2

En el dia de ayer, una empresa a la que a veces le presto servicios me llamo porque estaban teniendo fallas con su servicio de correo.

El primer paso que hice, fue revisar los logs, y al hacerlo me encontre con estos errores que ocurrian con varios Dominios:

dsn=4.4.2, status=deferred (lost connection with alt1.gmail-smtp-in.l.google.com[209.85.222.27] while sending message body)

dsn=4.4.2, status=deferred (lost connection with f.mx.mail.yahoo.com[98.137.54.237] while sending end of data -- message may be sent more than once)

Estos errores tienden a ser por problemas de latencia, que la transmision del correo se cierra debido al delay que se presenta, pero para mi sorpresa, el enlace estaba bien, no habia latencia en la red de la empresa.

Intente disminuir el MTU de la interfaz eth0:

debian:/home/xxxx# ifconfig eth0 mtu 1000
debian:/home/xxxx# ifconfig
eth0 Link encap:Ethernet HWaddr 00:1a:4b:5e:10:c8
inet addr:10.10.10.10 Bcast:192.168.127.255 Mask:255.255.255.0
UP BROADCAST MULTICAST MTU:1000 Metric:1

Pense que esto iba a solucionarlo, pero no fue asi, despues de correr "mailq -q" para forzar la salida de los correos en cola, los mismos se mantenian en las mismas condiciones.

Capaz era problema se relacionaba con el MTU discovery

"debian:/home/xxxx#echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc"

Luego de volver a correr "mailq -q", seguia dando el mismo error.


Por lo que procedi a instalar tcpdump "debian:/home/xxxx# aptitude install tcpdump" y sniffear el trafico del puerto 25.

"debian:/home/xxxx# tcpdump -i eth0 port 25"

Y lo deje corriendo un rato, mientras enviaba correos a la empresa y de la empresa enviaba correos a otros dominios. Luego de obtener bastante informacion procedi a analizarla con Wireshark (esta herramienta es lo mejor creado por el ser Humano, junto con nmap :P).

Comparte con ustedes lo que vi en Wireshark


Al ver el error que estaba teniendo en cuanto al "TCP checksum offload", procedi a deshabilitarlo en la interfaz eth0.

Esto se puede hacer con una herramienta que se llama ethtool, que te permite manipular las propiedades de la interfaz.


debian:/home/xxxx# ethtool --show-offload eth0
Offload parameters for eth0:
Cannot get device rx csum settings: Operation not supported
Cannot get device flags: Operation not supported
rx-checksumming: off
tx-checksumming: on <============
scatter-gather: off
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off
large receive offload: off

debian:/home/xxxx# ethtool --offload eth0 tx off

y luego

debian:/home/xxxx# ethtool --show-offload eth0
Offload parameters for eth0:
Cannot get device rx csum settings: Operation not supported
Cannot get device flags: Operation not supported
rx-checksumming: off
tx-checksumming: off <============ :)
scatter-gather: off
tcp segmentation offload: off
udp fragmentation offload: off
generic segmentation offload: off
large receive offload: off


Al hacer esto, los correos empezaron a salir :)....

Para quienes no tengan muy claro que es esto, les dejo una pequenha nota;

"If you are experiencing network problems and while trying to figure
it out with Wireshark you found these checksum errors, you may have a
network card with TCP checksum offload enabled and for some reason the
packet is not being fixed by the adapter (NAT, bridge or route
redirection is sending the packet to another interface). In this case,
you may want to check and disable checksum offload for the adapter, if
possible."

Mas detallado:

"tcp checksum offloading will not offer you very much performance wise
since it is so cheap to calculate it with the CPU. tcp checksum
offloading is dangerous for data however since it means that you will
send your packets across the least reliable component of your computer
(the pci bus) and without tcp checksum calculated by the stack you
will not detect bits being flipped/corrupted by the pci bus and thus
data might be corrupted. tcp checksum offloading is not as good as it
initially might be thought."

BGP Stream: un año de análisis sobre incidentes BGP

BGP Stream: un año de análisis sobre incidentes BGP 04/03/2024 Por  Alejandro Acosta , Coordinador de I+D en LACNIC LACNIC presenta  la prim...