Hola,
Este post es muy corto pero quizas muy util. Hay menos documentacion en Internet que la esperada.
Objetivo:
a) Configurar los DNS reversos y los DNS forward de una red /24 en BIND9 utilizando $GENERATE.
b) Que coincida la resolucion forward a la resolucion reversa
Requisitos:
- Una red /24 (claro, el ejemplo se puede ajustar a otras redes)
- BIND9
- Usaremos registros A y PTR
Ejemplo:
La red 192.168.30.0/24
Dominio: ejemplo.com
Vamos a hacer que los reversos de 192.168.30.X resuelvan a: X.cliente.ejemplo.com
De igual manera, X.cliente.ejemplo.com resolverá a 192.168.30.X
Sería así:
192.168.30.1 ---> 1.cliente.ejemplo.com
192.168.30.2 ---> 2.cliente.ejemplo.com
192.168.30.3 ---> 3.cliente.ejemplo.com
1.cliente.ejemplo.com ---> 192.168.30.1
2.cliente.ejemplo.com ---> 192.168.30.2
3.cliente.ejemplo.com ---> 192.168.30.3
(etc)
Pasos:
Creamos la zona reversa en /etc/bind/named.conf.
a) La zona reversa:
zone "30.168.192.in-addr.arpa" {
type master;
file "30.168.192.in-addr.arpa.db";
allow-query { any; };
};
Luego en el archivo 30.168.192.in-addr.arpa.db colocamos lo siguiente:
$TTL 86400 ; 24 hours, could have been written as 24h or 1d
@ 1D IN SOA localhost. hostmaster.ejemplo.com. (
2002022401 ; serial
3H ; refresh
15 ; retry
1w ; expire
3h ; minimum
)
; Name servers for the zone - both out-of-zone - no A RRs required
NS localhost.
$GENERATE 1-255 $ PTR $.cliente.ejemplo.com.
b) La zona forward, utilizando registros A es:
$TTL 86400 ; 24 hours, could have been written as 24h or 1d
@ 1D IN SOA localhost. hostmaster.ejemplo.com. (
2002022401 ; serial
3H ; refresh
15 ; retry
1w ; expire
3h ; minimum
)
; Name servers for the zone - both out-of-zone - no A RRs required
NS localhost.
$GENERATE 1-255.cliente.ejemplo.com $ A 192.168.30.$
Pruebas:
Para probar:
#dig -x 192.168.30.3 (reverso dns)
#dig 3.cliente.ejemplo.com (forward dns)
Espero haya sido de utilidad
Mostrando entradas con la etiqueta servidor. Mostrar todas las entradas
Mostrando entradas con la etiqueta servidor. Mostrar todas las entradas
lunes, 17 de noviembre de 2014
sábado, 5 de abril de 2014
Solucion a tres errores cuando queremos arrancar ISC DHCP 4.3
Error 1:
Can't open lease database /var/lib/dhcp/dhcpd6.leases: No such file or directory --
check for failed database rewrite attempt!
Ejemplo:
root@IPv6-RTR:/etc# /usr/sbin/dhcpd -6 -f -cf /etc/dhcp/dhcpd.conf eth5
Internet Systems Consortium DHCP Server 4.3.0a1
Copyright 2004-2013 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Can't open lease database /var/lib/dhcp/dhcpd6.leases: No such file or directory --
check for failed database rewrite attempt!
Please read the dhcpd.leases manual page if you
don't know what to do about this.
root@IPv6-RTR:/etc# touch /var/lib/dhcp/dhcpd6.leases
Solucion a error 1:
#touch /var/lib/dhcp/dhcpd6.leases
Adicionalmente verificar si el usuario con el que se esta ejecutando dhcpd posee escritura en /var/lib/dhcp
Quizas tambien hay que:
#cd /var/lib/
#chown -R root.root dhcp
--------------------------
Error 2:
No subnet6 declaration for eth5 (fe80::a00:27ff:fee7:b7c)
Ejemplo del error:
root@IPv6-RTR:/etc/dhcp# /usr/sbin/dhcpd -6 -f -cf /etc/dhcp/dhcpd.conf eth5
Internet Systems Consortium DHCP Server 4.3.0a1
Copyright 2004-2013 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Wrote 0 NA, 0 TA, 0 PD leases to lease file.
No subnet6 declaration for eth5 (fe80::a00:27ff:fee7:b7c).
** Ignoring requests on eth5. If this is not what
you want, please write a subnet6 declaration
in your dhcpd.conf file for the network segment
to which interface eth5 is attached. **
Not configured to listen on any interfaces!
Solucion a error 2:
Quitar la declaracion de subnet6 en dhcpd6.conf y copiarla a dhcpd.conf
-------------------------
Error 3:
Can't set SO_REUSEPORT option on dhcp socket: Protocol not available
Ejemplo del error:
root@IPv6-RTR:/etc/dhcp# /usr/sbin/dhcpd -6 -f -cf /etc/dhcp/dhcpd.conf eth5
Internet Systems Consortium DHCP Server 4.3.0a1
Copyright 2004-2013 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Wrote 0 NA, 0 TA, 0 PD leases to lease file.
Can't set SO_REUSEPORT option on dhcp socket: Protocol not available
Solucion a error 3:
Actualizar el kernel a una version >= 3.9
SO_REUSEPORT es requerido por ISC DHCP 4.3 por ello es necesario tener un kernel > 3.9
miércoles, 2 de abril de 2014
Instalar ISC DHCP 4.3 en Linux (Ubuntu 13.04) (IPv6)
Situacion:
Deseo instalar DHCP ISC 4.3 en Linux para mejorar el soporte de DHCP para IPv6.
Procedimiento:
1) Agregar la siguiente linea al final de /etc/apt/sources.list:
deb http://ftp.de.debian.org/debian experimental main
2) Eliminar cualquier dhcp de ISC que tuviesemos antes:
#apt-get purge isc-dhcp-server (notese que podemos usar purge o remove, lo dejo a tu criterio)
3) Actualizar la DB de repositorios:
#apt-get update
4) Instalar el isc-dhcp-server indicando que use el repositorio experimental:
#apt-get -t experimental install isc-dhcp-server
Importante:
La configuracion del DHCP(d) debe estar funcionando, sino, el DHCPD no levantara y dara un error (logico, no?)
Más información:
http://blog.acostasite.com/2014/04/solucion-tres-errores-cuando-queremos.html
Deseo instalar DHCP ISC 4.3 en Linux para mejorar el soporte de DHCP para IPv6.
Procedimiento:
1) Agregar la siguiente linea al final de /etc/apt/sources.list:
deb http://ftp.de.debian.org/debian experimental main
2) Eliminar cualquier dhcp de ISC que tuviesemos antes:
#apt-get purge isc-dhcp-server (notese que podemos usar purge o remove, lo dejo a tu criterio)
3) Actualizar la DB de repositorios:
#apt-get update
4) Instalar el isc-dhcp-server indicando que use el repositorio experimental:
#apt-get -t experimental install isc-dhcp-server
Importante:
La configuracion del DHCP(d) debe estar funcionando, sino, el DHCPD no levantara y dara un error (logico, no?)
Más información:
http://blog.acostasite.com/2014/04/solucion-tres-errores-cuando-queremos.html
viernes, 7 de diciembre de 2012
Solucion: Apache solo escucha sobre IPv6
Situación:
Apache solo funciona sobre IPv6
Troubleshoooting:
a) Para que escuche en IPv4:
- Editar el archivo /etc/apache2/ports.conf
- En la directiva Listen colocar
Listen 192.168.1.10:80
Se pueden colocar varias directivas Listen. Tales como:
Listen 192.168.1.10:80
Listen 127.0.0.1:80
Para escuchar en todo IPv4 (cualquier IPv4 configurado en el server):
Listen 0.0.0.0:80
b) Para escuchar en IPv6:
- Editar el archivo /etc/apache2/ports.conf
- En la directiva Listen colocar <[direccionIPv6]:puerto>. Por ejemplo:
Listen [2001:db8::4]:80
Reiniciar apache..., por ejemplo: /etc/init.d/apache2 restart
Diagnóstico:
Para saber que servicios, a que direcciones IP escucha y que proceso esta asociado recomiendo utilizar el comando: netstat -pan
#netstat -pan | more
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 965/mysqld
tcp 0 0 127.0.0.1:587 0.0.0.0:* LISTEN 1020/sendmail: MTA:
tcp 0 0 0.0.0.0:10000 0.0.0.0:* LISTEN 1162/perl
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 8478/vsftpd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 816/sshd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1020/sendmail: MTA:
tcp 0 0 192.168.1.10:22 192.168.1.2:57997 ESTABLISHED 19601/sshd: aacosta
tcp6 0 0 ::1:587 :::* LISTEN 1020/sendmail: MTA:
tcp6 0 0 :::80 :::* LISTEN 1134/apache2
tcp6 0 0 :::22 :::* LISTEN 816/sshd
En el extracto anterior la ultima linea indica que se está escuchando en todas las direcciones IPv6 (se puede comprender gracias a la culumna de la izquiera que indica tcp6 y luego en la cuarta columa indica ::22). El puerto está en estado listen por el proceso sshd y el pid 816
Para el primera linea se entiende que mysqld está escuchando en la dirección IPv4 127.0.0.1 en el puerto 3306 bajo el pid (process id) 965. Es decir, mysql no esta habilitado para escuchar conexiones de red (solo escucha localhost)
Mas información:
- http://serverfault.com/questions/332409/how-to-set-apache-virtualhost-to-work-with-ipv6- http://www.linuxweblog.com/blogs/sandip/20081027/forcing-apache-listen-ipv4
- http://www.linuxask.com/questions/limit-apache-only-listen-to-ipv4-address
Apache solo funciona sobre IPv6
Troubleshoooting:
a) Para que escuche en IPv4:
- Editar el archivo /etc/apache2/ports.conf
- En la directiva Listen colocar
Listen 192.168.1.10:80
Se pueden colocar varias directivas Listen. Tales como:
Listen 192.168.1.10:80
Listen 127.0.0.1:80
Para escuchar en todo IPv4 (cualquier IPv4 configurado en el server):
Listen 0.0.0.0:80
b) Para escuchar en IPv6:
- Editar el archivo /etc/apache2/ports.conf
- En la directiva Listen colocar <[direccionIPv6]:puerto>. Por ejemplo:
Listen [2001:db8::4]:80
Reiniciar apache..., por ejemplo: /etc/init.d/apache2 restart
Diagnóstico:
Para saber que servicios, a que direcciones IP escucha y que proceso esta asociado recomiendo utilizar el comando: netstat -pan
#netstat -pan | more
tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN 965/mysqld
tcp 0 0 127.0.0.1:587 0.0.0.0:* LISTEN 1020/sendmail: MTA:
tcp 0 0 0.0.0.0:10000 0.0.0.0:* LISTEN 1162/perl
tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 8478/vsftpd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 816/sshd
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1020/sendmail: MTA:
tcp 0 0 192.168.1.10:22 192.168.1.2:57997 ESTABLISHED 19601/sshd: aacosta
tcp6 0 0 ::1:587 :::* LISTEN 1020/sendmail: MTA:
tcp6 0 0 :::80 :::* LISTEN 1134/apache2
tcp6 0 0 :::22 :::* LISTEN 816/sshd
En el extracto anterior la ultima linea indica que se está escuchando en todas las direcciones IPv6 (se puede comprender gracias a la culumna de la izquiera que indica tcp6 y luego en la cuarta columa indica ::22). El puerto está en estado listen por el proceso sshd y el pid 816
Para el primera linea se entiende que mysqld está escuchando en la dirección IPv4 127.0.0.1 en el puerto 3306 bajo el pid (process id) 965. Es decir, mysql no esta habilitado para escuchar conexiones de red (solo escucha localhost)
Mas información:
- http://serverfault.com/questions/332409/how-to-set-apache-virtualhost-to-work-with-ipv6- http://www.linuxweblog.com/blogs/sandip/20081027/forcing-apache-listen-ipv4
- http://www.linuxask.com/questions/limit-apache-only-listen-to-ipv4-address
domingo, 15 de julio de 2012
Clave por defecto de Ubuntu Server
Situacion:
Luego de instalar Ubuntu Server (12.04 LTS) no puedo entrar como root ni hacer un "su" al usuario. El resto de los usuarios funcionan bien
Explicación:
Luego de la instalación, por defecto Ubuntu viene con el usuario root bloqueado, esto se puede verificar en /etc/shadow y ver el signo de exclamación (!) en el usuario root
Solución:
Existen muchas maneras de solucionar la situación. La más sencilla y funcional:
$sudo -i
#passwd root
Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
Luego de esto el usuario root quedará habilitado
Suerte!
Luego de instalar Ubuntu Server (12.04 LTS) no puedo entrar como root ni hacer un "su" al usuario. El resto de los usuarios funcionan bien
Explicación:
Luego de la instalación, por defecto Ubuntu viene con el usuario root bloqueado, esto se puede verificar en /etc/shadow y ver el signo de exclamación (!) en el usuario root
Solución:
Existen muchas maneras de solucionar la situación. La más sencilla y funcional:
$sudo -i
#passwd root
Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
Luego de esto el usuario root quedará habilitado
Suerte!
lunes, 18 de junio de 2012
Cliente SSH dura varios segundos para conectarse
Otro post sumamente rápido (pero útil):
Caso:
Cuando intento conectarme a un servidor SSH (Linux server) el mismo dura varios segundos antes de pedir login/password.
Esto es muy comun en servidores que no tienen acceso a Internet o DNSs mal configurados.
Ocurre que cuando intentamos conectarnos al SSH Server intenta hacer una solicitud de DNS reverso para IP origen (de donde nos intentamos conectar).
Por ejemplo, si quiero conectarme desde el equipo 192.168.1.2 al servidor SSH ubicado en el IP 10.1.1.21, este último, durante la conexión intentará buscar el reverso del IP 192.168.1.2. El tiempo que vemos antes de obtener "Login" es precisamente el timeout del SSH Server durante la operación DNS.
Solución:
La solución es sumamente sencilla, existen dos manera:
1) Si siempre nos vamos a conectar desde la misma dirección IP (o muy pocas diferentes):
En el servidor editar el archivo /etc/hosts y colocar los IPs de origen desde donde me conectaré. ejemplo:
192.168.1.2 blog.acostasite.com aacostaPC
192.168.1.3 www.lomejordelemail.com miPC
2) La solución alternativa es colocar al final del archivo /etc/ssh/sshd_config
UseDNS no
Caso:
Cuando intento conectarme a un servidor SSH (Linux server) el mismo dura varios segundos antes de pedir login/password.
Esto es muy comun en servidores que no tienen acceso a Internet o DNSs mal configurados.
Ocurre que cuando intentamos conectarnos al SSH Server intenta hacer una solicitud de DNS reverso para IP origen (de donde nos intentamos conectar).
Por ejemplo, si quiero conectarme desde el equipo 192.168.1.2 al servidor SSH ubicado en el IP 10.1.1.21, este último, durante la conexión intentará buscar el reverso del IP 192.168.1.2. El tiempo que vemos antes de obtener "Login" es precisamente el timeout del SSH Server durante la operación DNS.
Solución:
La solución es sumamente sencilla, existen dos manera:
1) Si siempre nos vamos a conectar desde la misma dirección IP (o muy pocas diferentes):
En el servidor editar el archivo /etc/hosts y colocar los IPs de origen desde donde me conectaré. ejemplo:
192.168.1.2 blog.acostasite.com aacostaPC
192.168.1.3 www.lomejordelemail.com miPC
2) La solución alternativa es colocar al final del archivo /etc/ssh/sshd_config
UseDNS no
Más información:
Espero haya sido útil.
sábado, 26 de mayo de 2012
Como instalar un root server local (DNS).
Hola,
Recientemente en algunas listas de discusión que sigo se hablaba sobre instalar un servidor DNS root server local, en fin, me llamó la curiosidad y lo hice solo por razones académicas.
He escuchado que esto de alguna manera puede mejorar el performance de alguna red, sobre todo en el mundo de los ISPs, sin embargo, en lo personal no lo veo necesario, lo dejo al criterio de cada uno de ustedes.
Laboratorio:
- Dos servidores y un cliente: Un servidor con Ubuntu, otro con Mandriva, el cliente también fue Mandriva. Donde:
* Servidor Mandriva como Root Server (Nombre Z, IP=192.168.127.68)
* Servidor Ubuntu como Servidor DNS recursivo (IP=192.168.127.86)
Primero:
1) Logicamente probar que el servidor recursivo funcione correctamente
2) Posteriormente, editar el archivo db.root de Ubuntu y dejar algo similar a:
;
. 3600000 IN NS Z.ROOT-SERVERS.NET.
Z.ROOT-SERVERS.NET. 3600000 A 192.168.127.68
; End of File
Espero haya sigo útil.
Recientemente en algunas listas de discusión que sigo se hablaba sobre instalar un servidor DNS root server local, en fin, me llamó la curiosidad y lo hice solo por razones académicas.
He escuchado que esto de alguna manera puede mejorar el performance de alguna red, sobre todo en el mundo de los ISPs, sin embargo, en lo personal no lo veo necesario, lo dejo al criterio de cada uno de ustedes.
Laboratorio:
- Dos servidores y un cliente: Un servidor con Ubuntu, otro con Mandriva, el cliente también fue Mandriva. Donde:
* Servidor Mandriva como Root Server (Nombre Z, IP=192.168.127.68)
* Servidor Ubuntu como Servidor DNS recursivo (IP=192.168.127.86)
Primero:
1) Logicamente probar que el servidor recursivo funcione correctamente
2) Posteriormente, editar el archivo db.root de Ubuntu y dejar algo similar a:
;
. 3600000 IN NS Z.ROOT-SERVERS.NET.
Z.ROOT-SERVERS.NET. 3600000 A 192.168.127.68
; End of File
Notese que realmente lo que hice fue eliminar los root servers tradicionales y agregar las lineas correspondientes a Z.ROOT-SERVERS.NET (Z es el nombre del mi root server y 192.168.127.68 es la dirección).
Logicamente sin haber más hints de root server, el servidor recursivo se verá forzado a utilizar Z como root server.
Nota:
En /var/log/syslog luego de reiniciar BIND puedes conseguir una línea similar a la siguiente:
May 25 19:05:16 ubuntu named[4953]: checkhints: extra NS 'Z.ROOT-SERVERS.NET' in hints
Segundo:
Aqui es donde realmente instalamos el root server en el servidor Mandriva (que realmente es muy sencillo).
1) Bajar el archivo root.zone de: http://www.iana.org/about/popular-links/
2) En el archivo /etc/named.conf del root server hay que modificar el siguiente renglón:
zone "." {
type hint;
file "/etc/bind/db.root";
};
Por:
zone "." {
type master;
file "/etc/bind/root.zone";
};
El archivo root.zone debe estar ubicado en el directorio correspondiente, en mi caso fue en /var/lib/named/var/named/, posteriormente hay que reiniciar y ya. En el root server ni siquiera hay que estar pendiente de recursividad y esas cosas porque este tipo de servidor tradionalmente no debe ni necesita hacer esta operación.
Tercero:
Probar desde el cliente:
[root@localhost ~]# dig blog.acostasite.com
; <<>> DiG 9.8.0-P4 <<>> blog.acostasite.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26771
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 2, ADDITIONAL: 0
;; QUESTION SECTION:
;blog.acostasite.com. IN A
;; ANSWER SECTION:
blog.acostasite.com. 0 IN CNAME cf-protected-blog.acostasite.com.
cf-protected-blog.acostasite.com. 300 IN A 108.162.198.198
cf-protected-blog.acostasite.com. 300 IN A 108.162.195.100
;; AUTHORITY SECTION:
acostasite.com. 172800 IN NS bob.ns.cloudflare.com.
acostasite.com. 172800 IN NS leah.ns.cloudflare.com.
;; Query time: 199 msec
;; SERVER: 192.168.127.86#53(192.168.127.86)
;; WHEN: Fri May 25 19:34:24 2012
;; MSG SIZE rcvd: 152
Mas información:
Espero haya sigo útil.
lunes, 9 de abril de 2012
Router (o LAN Switch) Cisco como servidor NTP
Escenario:
Deseo que mi Router Cisco se comporte como un servidor NTP. En realidad es algo SUPER sencillo pero lo deseo colocar aquí como referencia, estoy seguro que más de uno ha tenido esta necesidad.
Antes de continuar recueden que cualquier servicio que se habilita sobre un dispositivo trae consigo "huecos" de seguridad, dicho esto, en caso de no necesitar levantar el servicio NTP, por favor no lo hagan.
Configuracion del lado del Router (o Switch) _servidor_ :
a) Entrar en modo de configuracion (conf t)
b) ntp master [stratum]
ejemplo:
MIROUTER(config)# ntp master 3
LISTO!. Posteriormente, a partir de este momento ya el router se convierte en un NTP Server
Desde otro equipo solo hay que especificar como NTP Server el IP del Router Cisco. Ahora supongamos que el cliente es otro router Cisco, una configuración pudiese ser:
MILANSWITCH(config)#ntp server 192.168.12.1 source loopback 10
Recomiendo colocar el timezone de la ubicación de uno. Por ejemplo para Venezuela podemos usar:
MILANSWITCH(config)#clock timezone VEN -4 30 quedará precisa
Mas informacion:
http://www.cisco.com/en/US/docs/ios/12_1/configfun/configuration/guide/fcd303.html
Network Time Protocol
Deseo que mi Router Cisco se comporte como un servidor NTP. En realidad es algo SUPER sencillo pero lo deseo colocar aquí como referencia, estoy seguro que más de uno ha tenido esta necesidad.
Antes de continuar recueden que cualquier servicio que se habilita sobre un dispositivo trae consigo "huecos" de seguridad, dicho esto, en caso de no necesitar levantar el servicio NTP, por favor no lo hagan.
Configuracion del lado del Router (o Switch) _servidor_ :
a) Entrar en modo de configuracion (conf t)
b) ntp master [stratum]
LISTO!. Posteriormente, a partir de este momento ya el router se convierte en un NTP Server
Desde otro equipo solo hay que especificar como NTP Server el IP del Router Cisco. Ahora supongamos que el cliente es otro router Cisco, una configuración pudiese ser:
MILANSWITCH(config)#ntp server 192.168.12.1 source loopback 10
Recomiendo colocar el timezone de la ubicación de uno. Por ejemplo para Venezuela podemos usar:
MILANSWITCH(config)#clock timezone VEN -4 30 quedará precisa
Mas informacion:
http://www.cisco.com/en/US/docs/ios/12_1/configfun/configuration/guide/fcd303.html
Network Time Protocol
martes, 22 de noviembre de 2011
Certificacion IPv6 de Hurricane Electric
En esta oportunidad voy a dejarles mis impresiones sobre la certificacion IPv6 que tiene Hurricane Electric en http://ipv6.he.net/certification
na primera oportunidad la habia ignorado pero en esta oportunidad la curiosidad me llamo.
Les comento que me parece muy interesante la misma; me gusta la manera como esta organizada. Les cuento un poco:
- La certificacion se puede hacer por pasos y en varios dias. Esto da bastante comodidad.
- Para cada nivel te mandan a hacer varias "tareas" tales como: Configurar un servidor Web, de Correo, DNS, prueban conectividad a equipos tuyos etc.
- Es didactica y divertida
- Logicamente para comenzar la certificacion debes estar desde una maquina IPv6
- Existen varios niveles de certificacion: Newbie, Entusiasta, Administrator, Professional, Guru, Sage. A pesar de que me agrada la idea de varios niveles, creo que los nombres le quedan grande al nivel, por ejemplo, obtener el grado de Administrator me parece sencillo y su nombre suena casi a experto.
- Te mandan una franela/remera gratis de IPv6!!!!
Desde mi punto de vista las personas que manejen servidores y conectividad directamente tienen una enorme ventaja sobre los que no.
Consejos previos para prepararse para la certificacion:
- Como recomendacion, antes de comentar el examen, tengan un dominio con el cual puedan trabajar, quiero decir, que puedas crear zonas, modificar registros, etc.
- Maquina servidor (preferiblemente Linux) con conectividad a IPv6
- Acceso y configuracion a servicios tales como Web Server y Mail Server
Mas informacion
- La pagina para los que esten interesados es: http://ipv6.he.net/certification/
- En este blog hay mucha informacion sobre IPv6 sobre Linux y algunos servicios como Apache y Sendmail http://acostanetwork.blogspot.com
Saludos y suerte a los que deseen tomar la certificacion!!.
na primera oportunidad la habia ignorado pero en esta oportunidad la curiosidad me llamo.
Les comento que me parece muy interesante la misma; me gusta la manera como esta organizada. Les cuento un poco:
- La certificacion se puede hacer por pasos y en varios dias. Esto da bastante comodidad.
- Para cada nivel te mandan a hacer varias "tareas" tales como: Configurar un servidor Web, de Correo, DNS, prueban conectividad a equipos tuyos etc.
- Es didactica y divertida
- Logicamente para comenzar la certificacion debes estar desde una maquina IPv6
- Existen varios niveles de certificacion: Newbie, Entusiasta, Administrator, Professional, Guru, Sage. A pesar de que me agrada la idea de varios niveles, creo que los nombres le quedan grande al nivel, por ejemplo, obtener el grado de Administrator me parece sencillo y su nombre suena casi a experto.
- Te mandan una franela/remera gratis de IPv6!!!!
Desde mi punto de vista las personas que manejen servidores y conectividad directamente tienen una enorme ventaja sobre los que no.
Consejos previos para prepararse para la certificacion:
- Como recomendacion, antes de comentar el examen, tengan un dominio con el cual puedan trabajar, quiero decir, que puedas crear zonas, modificar registros, etc.
- Maquina servidor (preferiblemente Linux) con conectividad a IPv6
- Acceso y configuracion a servicios tales como Web Server y Mail Server
Mas informacion
- La pagina para los que esten interesados es: http://ipv6.he.net/certification/
- En este blog hay mucha informacion sobre IPv6 sobre Linux y algunos servicios como Apache y Sendmail http://acostanetwork.blogspot.com
Saludos y suerte a los que deseen tomar la certificacion!!.
viernes, 1 de octubre de 2010
Sendmail e IPv6. Hacer que sendmail escuche en IPv6
Problema:
Tengo un servidor de correo en Linux Debian con Sendmail, en IPv4 todo funciona bien pero no escucha conexiones en IPv6
Escenario:
Servidor Debian con Sendmail 8.14.3 e IPv6 configurado
Procedimiento:
Primero verificar que efectivamente Sendmail no escucha en IPv6. Por ejemplo:
#netstat -pan | grep sendmail
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 2596/sendmail: MTA:
unix 2 [ ACC ] STREAM LISTENING 4198 1025/mysqld / var/run/mysqld/mysqld.sock
unix 2 [ ACC ] STREAM LISTENING 13539 2596/sendmail: MTA: / var/run/sendmail/mta/smcontrol
unix 2 [ ] DGRAM 13535 2596/sendmail: MTA:
En la salida anterior notamos que sendmail se encuentra escuchando solo sobre la red IPv4.
Solucion:
La solucion es indicarle al Sendmail que también levante sobre la familia Inet6. Para ello es necesario modificar el sendmail.mc para reconstruir el sendmail.cf y luego reiniciar el sendmail. Los pasos son los siguientes:
1) Editar el sendmail.mc y agregar las siguientes lineas:
DAEMON_OPTIONS(`Family=inet6, Name=MTA-v6, Port=smtp, Addr=DIRIPV6')dnl
DAEMON_OPTIONS(`Family=inet6, Name=MSP-v6, Port=submission, M=Ea, Addr=::1')dnl
OJO: Sustituir DIRIPV6 por tu dirección IPv6
2) Ejecutar sendmailconfig (para procedar el sendmail.mc con m4 y generar el .cf)
3) Luego de ejecutar el comando anterior lo siguiente es siempre indicarle que Y en las siguientes preguntas:
Configure sendmail with the existing /etc/mail/sendmail.conf? [Y] y
Configure sendmail with the existing /etc/mail/sendmail.mc? [Y] y
Reload the running sendmail now with the new configuration? [Y] y
Verificar:
Para verificar ejecuta el comando:
#netstat -pan | grep sendmail
Realiza un telnet de la siguiente manera:
#telnet ::1 25
debes recibir respuesta similar a:
Trying ::1...
Connected to ::1.
Escape character is '^]'.
220 ipv6.para.com ESMTP Sendmail 8.14.3/8.14.3/Debian-9.1ubuntu1; Fri, 1 Oct 20 10 11:52:48 -0430; (No UCE/UBE) logging access from: localhost(OK)-localhost [IPv6:::1]
Suerte, espero haya sido util.
Tengo un servidor de correo en Linux Debian con Sendmail, en IPv4 todo funciona bien pero no escucha conexiones en IPv6
Escenario:
Servidor Debian con Sendmail 8.14.3 e IPv6 configurado
Procedimiento:
Primero verificar que efectivamente Sendmail no escucha en IPv6. Por ejemplo:
#netstat -pan | grep sendmail
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN 2596/sendmail: MTA:
unix 2 [ ACC ] STREAM LISTENING 4198 1025/mysqld / var/run/mysqld/mysqld.sock
unix 2 [ ACC ] STREAM LISTENING 13539 2596/sendmail: MTA: / var/run/sendmail/mta/smcontrol
unix 2 [ ] DGRAM 13535 2596/sendmail: MTA:
En la salida anterior notamos que sendmail se encuentra escuchando solo sobre la red IPv4.
Solucion:
La solucion es indicarle al Sendmail que también levante sobre la familia Inet6. Para ello es necesario modificar el sendmail.mc para reconstruir el sendmail.cf y luego reiniciar el sendmail. Los pasos son los siguientes:
1) Editar el sendmail.mc y agregar las siguientes lineas:
DAEMON_OPTIONS(`Family=inet6, Name=MTA-v6, Port=smtp, Addr=DIRIPV6')dnl
DAEMON_OPTIONS(`Family=inet6, Name=MSP-v6, Port=submission, M=Ea, Addr=::1')dnl
OJO: Sustituir DIRIPV6 por tu dirección IPv6
2) Ejecutar sendmailconfig (para procedar el sendmail.mc con m4 y generar el .cf)
3) Luego de ejecutar el comando anterior lo siguiente es siempre indicarle que Y en las siguientes preguntas:
Configure sendmail with the existing /etc/mail/sendmail.conf? [Y] y
Configure sendmail with the existing /etc/mail/sendmail.mc? [Y] y
Reload the running sendmail now with the new configuration? [Y] y
Verificar:
Para verificar ejecuta el comando:
#netstat -pan | grep sendmail
Realiza un telnet de la siguiente manera:
#telnet ::1 25
debes recibir respuesta similar a:
Trying ::1...
Connected to ::1.
Escape character is '^]'.
220 ipv6.para.com ESMTP Sendmail 8.14.3/8.14.3/Debian-9.1ubuntu1; Fri, 1 Oct 20 10 11:52:48 -0430; (No UCE/UBE) logging access from: localhost(OK)-localhost [IPv6:::1]
Suerte, espero haya sido util.
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
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
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:
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:
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/
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 2010Sources 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
./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%
./resperf-report -s 127.0.0.1 -d queryfile-example-100thousand.orig -m 10
Ejemplo de la 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
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:
./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:
./resperf-report -s 127.0.0.1 -d queryfile-example-100thousand.orig -m 10
Ejemplo de la página Web:
- Ejemplo 1-3:
./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!,
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."
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."
Suscribirse a:
Entradas (Atom)
Una propuesta inesperada dentro de IETF – Ethernet sobre HTTPS
En el presente post quiero hablar mayormente sobre un documento con poco tiempo en IETF llamado “Ethernet sobre HTTPS”. Debo confesar que su...
