VPSs y mas.

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

lunes, 30 de enero de 2017

3 recomendaciones al construir el registro SOA en DNS

Hola, 
  En el presente artículo solo quiero mencionar 3 consejos que al parecer son difíciles de conseguir en Internet pero que son importantes..., hay MUCHOS otros consejos que se pueden dar, repito, voy a mencionar los que quizás no son tan conocidos y a su vez pueden traer problemas operacionales.

Recordando el fomato del registro SOA:
  Un pequeño ejemplo de un registro SOA sería (tomado de una instalación de Bind):
@ IN SOA localhost. root.localhost. (
     1 ; Serial
604800 ; Refresh
 86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
   De manera muy breve y explicándolo de manera muy entendible: 
El serial: se debe incrementar con cada modificación de la zona. Recordemos que este valor será revisado por los servidores DNS secundarios para identificar si existe algún cambio en la zona
Refresh: Cada cuando tiempo el servidor DNS secundario debe ir al servidor primario y revisar si hubo cambios (¿el valor de Serial es mayor? 
Retry: En caso de que el servidor secundario intentó comunicarse al primario y NO pudo (por la razón que fuese), cada cuanto lo vuelvo a intentar
Expire: Supongamos que el servidor secundario tiene N cantidad de tiempo "N=Expire" sin haber contactado al primario debería dejar de responder. Esto sale del principio que hace mucho que el secundario no contacta al servidor primario y la información que tenga ya puede haber cambiado, el servidor DNS secundario prefiere no dar respuesta que dar información errónea y/o desactualizada. Es decir, el servidor DEJA DE RESPONDER A LA ZONA
Negative Cache TTL: Hace referencia a cachear respuestas DNS negativas...., por ejemplo NXDOMAIN
Revisando lo anterior, nótese que los valores son casi exclusivamente utilizados por los servidores DNS Secundarios que desean hacer zone-transfer.

Consejo 1:
  El Serial nunca debería ser 0. El RFC 2136 indica en la sección 7: "Design, Implementation, Operation, and Protocol Notes". 
  7.11. A zone's SOA SERIAL should never be set to zero (0) due to
   interoperability" ...............

Consejo 2: 
  El valor de Retry no debería ser mayor a Refresh. La razón es bastante lógica, es casi como no tener valor de Retry.., primero ocurre el refresh. Adicionalmente Retry significa contactar el servidor primario para hacer el zone transfer SI NO se pudo contactar antes, con el Retry se buscar mantener la zona actualizada. RFC 1912 indica: ...... "Retry: If a secondary was unable to contact the primary at the
          last refresh, wait the retry value before trying again.  This
          value isn't as important as others, unless the secondary is on
          a distant network from the primary or the primary is more
          prone to outages.  It's typically some fraction of the refresh
          interval."

Consejo 3:
   El Expire no debe ser menor al Refresh. Similar al consejo 2 pero incluso este lo considero más importante. Si yo tengo un Expire menor que el Refresh significa que el servidor secundario va a dejar de responder la zona antes de que un intento de actualización (Refresh). Obviamente esto no es lo que se quiere. En el RFC 1912 se lee: "Expire: How long a secondary will still treat its copy of the zone
          data as valid if it can't contact the primary.  This value
          should be greater than how long a major outage would typically
          last, and must be greater than the minimum and retry
          intervals"

Referencias:
- Libro: Cookbook for IPv6 Renumbering in SOHO and
Backbone Networks "https://hal.inria.fr/inria-00000888/file/D3.6.1.pdf"  página 50 indica:  "retry should be smaller than refresh"
- Guia: "Check Point™ Meta IP User’s Guide" pagina 114 indica: "Slave Refresh must be lower than Slave Data Expire and Zone Default TTL"
- Sobre el serial no debería ser 0:  https://mxtoolbox.com/problem/dns/dns-soa-serial-number-format y https://www.digitalocean.com/community/questions/soa-serial-number-format-is-invalid  (sin embargo algunos software de DNS lo aceptan)

lunes, 7 de diciembre de 2015

Configurando una red con DHCPv6 Server (Cisco), DHCPv6 relay (Linux - ISC) y como CPE un Router Cisco

Introducción
  Este post es muy similar al encontrado en:  http://blog.acostasite.com/2015/11/configurando-una-red-con-dhcpv6-server.html
  La principal diferencia es que en esta oportunidad tendremos el DHCPv6 Server en Cisco y no en Linux
  En el presente post vamos a explicar e implementar como trabajar con DHCPv6 Server, Relay y Cliente.
  Favor leer la sección: "Explicación de la topología" la cual indica cada función


Topología




Explicación de la topología

En la topología de arriba va a ocurrir lo siguiente:

- El Cisco DHCPv6 Server está entregando prefijos v6
- El DHCPv6 Relay (Debian) va a escuchar por la interfaz ethernet1 (e1) por peticiones DHCPv6 de Prefix Delegation (PD). Las mismas serán reenviadas por la interfaz ethernet0 (e0) al servidor DHCPv6 Server
- El Cisco Router DHCPv6 Client va a hacer solicitudes DHCPv6 PD en su interfaz f1/0, del prefijo recibido va a configurar su interfaz f0/0 y enviar Router Advertisements por dicha interfaz permitiendo a los clientes auto-configurarse. En esta oportunidad también configuraremos otras interfaces pero solo a manera de ejemplo.
- Los clientes conectados a la interfaz f0/0 en el Cisco DHCPv6 Cliente van a autoconfigurarse vía SLAAC utilizando el prefijo recibido por RA

  Nótese que para el Router Cisco DHCPv6 Client le es transparente el DHCPv6 Relay Server


Que necesitamos:

- Del lado del Relay el software Relay de DHCPv6 de ISC (que es diferente al server)
- El Router tiene que ser un enrutador que haga DHCPv6 cliente PD

Instalando
En el Relay Server:
  #sudo apt-get install isc-dhcp-relay

  Durante la instalación del relay se van a realizar varias preguntas. Puedes decidir contestarlas o no. Para este post no es necesario responderlas.


Configuraciones:

Del lado del Cisco DHCPv6 Server:

ipv6 unicast-routing
interface FastEthernet0/0
 ipv6 address 2001:DB8::1/64
 ipv6 dhcp server DHCPv6-SERVER
end

ipv6 dhcp pool DHCPv6-SERVER
 prefix-delegation pool MY-PD-1

ipv6 local pool MY-PD-1 2001:DB8:ABCD::/48 56


Explicando la configuración:
Primero se le indica al equipo que puede enrutar paquetes IPv6. Luego se configura IPs estáticas entre el relay y la interfaz f0/0 (revisar la ethernet0 del relay).
Luego, se le indica que la interfaz sirve como DHCPv6 Server y se le asigna el pool DHCPv6-Server, aquí podemos escribir cualquier nombre.

Dentro del pool DHCPv6-Server se le dice que haga prefix-delegation (se le puede indicar más información pero para nuestro propósito hasta aquí es suficiente) y que utilice un pool local llamado MY-PD-1. Este pool va a utilizar prefijos dentro de 2001:DB8:ABCD::/48 y entregará bloques /56 a sus clientes. Aquí podemos indicar el tamaño de prefijo que queremos.


Del lado del relay:
Red:
  #ifconfig eth0 inet6 add 2001:db8::2/64
  #ifconfig eth1 inet6 add 2001:db8:1::2/64

  No hay configuraciones. El relay es levantado con este comando:
  #dhcrelay -I -l eth1 -u eth0

Explicación del comando para ejecutar el dhcp-relay:
Hay muchas maneras y opciones para dhcrelay, en el comando anterior se esta diciendo: que se utilice el DHCPv6 interface-id option, que escuche peticiones por eth1 y las mismas sean enviadas por eth0


Del lado del Cisco Router DHCPv6 Cliente:

ipv6 unicast-routing
interface FastEthernet1/0
 description Hacia DHCPv6 Relay Server
 ipv6 address 2001:DB8:1::1/64
 ipv6 dhcp client pd IP-FROM-DHCPv6-SERVER
end

interface FastEthernet0/0
 description Hacia LAN
 ipv6 address IP-FROM-DHCPv6-SERVER ::1/64
end

Explicación de la configuración del router Cisco:
Primero se habilita el routing IPv6 en el equipo.
Segundo, en la interfaz F1/0 se le esta diciendo al router que es DHCP cliente para prefijos y le asignamos el nombre: IP-FROM-DHCPv6-SERVER
Tercero, en la interfaz f0/0 le indica al router que utilice el prefijo recibido via DHCPv6 client y asigne el mismo a la interfaz como ::1/64. Es decir, el router toma el /56 del DHCPv6 y el mismo router va a crear una /64 para f0/0 (nota que puedes configurar otras interfaces utilizando el mismo prefijo recibido por el DHCP). 


Para revisar:
Del lado del DHCPv6 Server deberiamos ver algo como:

a) Con el DHCPv6 server corriendo en foreground puedes ver:

DHCP-Server#debug ipv6 dhcp detail

Se veran mensajes como:

*Dec  1 09:55:14.619: IPv6 DHCP: Received RELAY-FORWARD from 2001:DB8::2 on FastEthernet0/0
*Dec  1 09:55:14.623: IPv6 DHCP: detailed packet contents
*Dec  1 09:55:14.623:   src 2001:DB8::2 (FastEthernet0/0)
*Dec  1 09:55:14.627:   dst FF05::1:3
*Dec  1 09:55:14.627:   type RELAY-FORWARD(12), hop 0
*Dec  1 09:55:14.627:   link 2001:DB8:1::2
*Dec  1 09:55:14.631:   peer FE80::C801:24FF:FE20:1C
*Dec  1 09:55:14.631:   option INTERFACE-ID(18), len 4
*Dec  1 09:55:14.635:     0x01000000
*Dec  1 09:55:14.639:   option RELAY-MSG(9), len 50
*Dec  1 09:55:14.639:     type SOLICIT(1), xid 2389101
*Dec  1 09:55:14.643:     option ELAPSED-TIME(8), len 2
*Dec  1 09:55:14.643:       elapsed-time 0
*Dec  1 09:55:14.647:     option CLIENTID(1), len 10
*Dec  1 09:55:14.647:       00030001CA0124200000
*Dec  1 09:55:14.647:     option ORO(6), len 6
*Dec  1 09:55:14.651:       IA-PD,DNS-SERVERS,DOMAIN-LIST
*Dec  1 09:55:14.655:     option IA-PD(25), len 12
*Dec  1 09:55:14.659:
DHCP-Server# IAID 0x00040001, T1 0, T2 0
*Dec  1 09:55:14.663: IPv6 DHCP: Using interface pool DHCPv6-SERVER
*Dec  1 09:55:14.667: IPv6 DHCP: Source Address from SAS 2001:DB8::1


b) DHCP-Server#sh ipv6 dhcp binding
Client: FE80::C801:24FF:FE20:1C
  DUID: 00030001CA0124200000
  Username : unassigned
  Interface : relayed
  IA PD: IA ID 0x00040001, T1 302400, T2 483840
    Prefix: 2001:DB8:ABCD::/56
            preferred lifetime 604800, valid lifetime 2592000
            expires at Dec 31 2015 09:55 AM (2589331 seconds)


Del lado del Cliente DHCPv6 Cisco:
Para revisar si la interfaz f0/0 se autoconfiguró cone l prefijo recibido por el DHCPv6:
a) R1#show ipv6 interface f0/0

Vamos a ver algo como:

R1#sh ipv6 int f0/0
FastEthernet0/0 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::C801:24FF:FE20:0
  No Virtual link-local address(es):
  Description: Hacia LAN
  General-prefix in use for addressing
  Global unicast address(es):
    2001:DB8:ABCD::1, subnet is 2001:DB8:ABCD::/64 [CAL/PRE]


Nótese que 2001:DB8:ABCD::/64 corresponde al prefijo configurado en el DHCPv6 Server que es entregado vía PD


Algo muy importante es el comando:

b) R1#show ipv6 dhcp

El cual muestra el DUID (DHCPv6 Unique ID) del equipo (RFC3315):
This device's DHCPv6 unique identifier(DUID): 00030001CA0124200000


Podemos apreciar que este mismo número es que le llega al DHCPv6 Server


Del lado del cliente:
Depende de tu OS puedes hacer:
c:\ipconfig 

o

#ifconfig


¿Si hay más de una interfaz del lado del cliente?
En el ejemplo anterior el Cisco DHCPv6 Cliente está recibiendo un prefijo /56, esto quiere decir que tenemos hasta 8 redes /64 para crear. Hasta el momento solo hemos utilizado una en la f0/0.

De manera de ejemplo vamos a crear otras redes en las interfaces loopback0 y looback1 del router del lado del cliente.

interface Loopback0
 ipv6 address IP-FROM-DHCPv6-SERVER ::1:0:0:0:1/64
end

interface Loopback1
 ipv6 address IP-FROM-DHCPv6-SERVER ::2:0:0:0:1/64
end


La manera de construir los pseudo IPs (pe. ::1:0:0:0:1/64) colocados en la interfaz es la siguiente:
Imaginamos el prefijo recibido por DHCPv6, sabemos que es un /56. Lo que estamos haciendo es completando el resto del IP. 

Es decir: recibimos por DHCPv6 2001:db8:ABCD::/56. Al decirle a la loopback 1 ::1:0:0:0:1/64 construimos:  2001:db8:ABCD::1:0:0:0:1/64 (Prefijo recibido + la configuracion de la interfaz)


Vamos a revisar que IPs tienen entonces L0 y L1:

R1#sh ipv6 int l0
Loopback0 is up, line protocol is up
  Global unicast address(es):
    2001:DB8:ABCD:1::1, subnet is 2001:DB8:ABCD:1::/64 [CAL/PRE]


R1#sh ipv6 int l1
Loopback1 is up, line protocol is up
  Global unicast address(es):
    2001:DB8:ABCD:2::1, subnet is 2001:DB8:ABCD:2::/64 [CAL/PRE]


Proximos pasos
- Falta la parte de routing, hay muchas maneras de hacerlo, indiscutiblemente la intención es hacerlo con un protocolo de enrutamiento dinámico


Para más información:
https://tools.ietf.org/html/rfc6355
http://www.cisco.com/c/en/us/support/docs/ip/ip-version-6-ipv6/113141-DHCPv6-00.html
http://blog.acostasite.com/2014/04/instalar-isc-dhcp-43-en-linux-ubuntu.html
http://blog.acostasite.com/2014/04/solucion-tres-errores-cuando-queremos.html
http://blog.acostasite.com/2015/11/configurando-una-red-con-dhcpv6-server.html

lunes, 30 de noviembre de 2015

Configurando una red con DHCPv6 Server (ISC), DHCPv6 relay (ISC) y como CPE un Router Cisco

Introducción
  En el presente post vamos a explicar e implementar como trabajar con DHCPv6 Server, Relay y Cliente.
  Favor leer la sección: "Explicación de la topología" la cual indica cada función


Topología








Explicación de la topología

En la topología de arriba va a ocurrir lo siguiente:

- El Ubuntu DHCPv6 Server está entregando prefijos v6
- El DHCPv6 Relay va a escuchar por la interfaz ethernet1 (e1) por peticiones DHCPv6 de Prefix Delegation (PD). Las mismas serán reenviadas por la interfaz ethernet0 (e0) al servidor DHCPv6 Server
- El Cisco Router va a hacer solicitudes DHCPv6 PD en su interfaz f1/0, del prefijo recibido va a configurar su interfaz f0/0 y enviar Router Advertisements por dicha interfaz permitiendo a los clientes auto-configurarse
- El cliente se va a autoconfigurar utilizando el prefijo recibido por RA

  Nótese que para el Router Cisco le es transparente el DHCPv6 Relay Server


Que necesitamos:
- Del lado del server el servidor de ISC DHCPv6
- Del lado del ralay el relay de DHCPv6 de ISC (que es diferente al server)
- El Router tiene que ser un enrutador que haga DHCPv6 cliente PD

Instalando
En el Server Linux:
  #sudo apt-get install isc-dhcp-server
 
En el Relay Server:
  #sudo apt-get install isc-dhcp-relay

  Durante la instalación del relay se van a realizar varias preguntas. Puedes decidir contestarlas o no. Para este post no es necesario responderlas.


Configuraciones:

Del lado del Server:
Red:
#ifconfig eth1 ine6 add 2001:db8::2/64
#route -A inet6 add default gw 2001:db8::1

en /etc/dhcp/dhcpd.conf

default-lease-time 600;
max-lease-time 7200;
log-facility local7;
subnet6 2001:db8::/32 {

  #Prefix range for PD
  prefix6 2001:db8:1:100:: 2001:db8:1:f00 /56;

}


Explicacion de la configuracion dhcpd.conf:
La parte mas importante de la configuracion de arriba es la linea "prefix6" donde se indica el prefijo inicial y final /56 que los clientes van a recibir.

Para levantar el servicio de DHCPv6:
# /usr/sbin/dhcpd -6 -d -cf /etc/dhcp/dhcpd.conf eth0

Del lado del relay:
Red:
  #ifconfig eth0 inet6 add 2001:db8::2/64
  #ifconfig eth1 inet6 add 2001:db8:1::2/64

  No hay configuraciones. El relay es levantado con este comando:
  #dhcrelay -I -l eth1 -u eth0

Explicación del comando para ejecutar el dhcp-relay:
Hay muchas maneras y opciones para dhcrelay, en el comando anterior se esta diciendo: que se utilice el DHCPv6 interface-id option, que escuche peticiones por eth1 y las mismas sean enviadas por eth0


Del lado del Cisco Router:

ipv6 unicast-routing
interface FastEthernet1/0
 description Hacia DHCPv6 Relay Server
 ipv6 address 2001:DB8:1::1/64
 ipv6 dhcp client pd IP-FROM-DHCPv6-SERVER
end

interface FastEthernet0/0
 description Hacia LAN
 ipv6 address IP-FROM-DHCPv6-SERVER ::1/64
end

Explicación de la configuración del router Cisco:
Primero se habilita el routing IPv6 en el equipo.
Segundo, en la interfaz F1/0 se le esta diciendo al router que es DHCP cliente para prefijos y le asignamos el nombre: IP-FROM-DHCPv6-SERVER
Tercero, en la interfaz f0/0 le indica al router que utilice el prefijo recibido via DHCPv6 client y asigne el mismo a la interfaz como ::1/64. Es decir, el router toma el /56 del DHCPv6 y el mismo router va a crear una /64 para f0/0 (nota que puedes configurar otras interfaces utilizando el mismo prefijo recibido por el DHCP). 


Para revisar:
Del lado del DHCPv6 Server deberiamos ver algo como:

a) Con el DHCPv6 server corriendo en foreground puedes ver:

Relay-forward message from 2001:db8::2 port 547, link address 2001:db8:1::2, peer address fe80::c801:24ff:fe20:1c
Picking pool prefix 2001:db8:1:f00::/56
Advertise PD: address 2001:db8:1:f00::/56 to client with duid 00:03:00:01:ca:01:24:20:00:00 iaid = 262145 valid for 600 seconds
Wrote 0 NA, 0 TA, 1 PD leases to lease file.
Sending Relay-reply to 2001:db8::2 port 547
Relay-forward message from 2001:db8::2 port 547, link address 2001:db8:1::2, peer address fe80::c801:24ff:fe20:1c
Reply PD: address 2001:db8:1:f00::/56 to client with duid 00:03:00:01:ca:01:24:20:00:00 iaid = 262145 valid for 600 seconds
Sending Relay-reply to 2001:db8::2 port 547

b) Para revisar los leases:
# more /var/lib/dhcp/dhcpd6.leases


Del lado del router Cisco:
Para revisar si la interfaz f0/0 se autoconfiguró cone l prefijo recibido por el DHCPv6:
a) R1#show ipv6 interface f0/0


Vamos a ver algo como:

R1#sh ipv6 interface f0/0
FastEthernet0/0 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::C801:24FF:FE20:0
  No Virtual link-local address(es):
  Description: Hacia LAN
  General-prefix in use for addressing
  Global unicast address(es):
    2001:DB8:1:F00::1, subnet is 2001:DB8:1:F00::/64 [CAL/PRE]


Nótese que 2001:db8:1:f00/64 corresponde al prefijo configurado en el DHCPv6 Server que es entregado vía PD


Algo muy importante es el comando:

b) R1#show ipv6 dhcp

El cual muestra el DUID (DHCPv6 Unique ID) del equipo (RFC3315):
This device's DHCPv6 unique identifier(DUID): 00030001CA0124200000


Podemos apreciar que este mismo número es que le llega al DHCPv6 Server


Del lado del cliente:
Depende de tu OS puedes hacer:
c:\ipconfig 

o

#ifconfig


Proximos pasos
- Falta la parte de routing, hay muchas maneras de hacerlo, indiscutiblemente la intención es hacerlo con un protocolo de enrutamiento dinámico
- En el próximo Post haremos exactamente lo mismo pero con el DHCPv6 Server que sea una caja Cisco.


Para más información:
- https://tools.ietf.org/html/rfc6355
- http://www.cisco.com/c/en/us/support/docs/ip/ip-version-6-ipv6/113141-DHCPv6-00.html
http://blog.acostasite.com/2014/04/instalar-isc-dhcp-43-en-linux-ubuntu.html
http://blog.acostasite.com/2014/04/solucion-tres-errores-cuando-queremos.html



martes, 28 de julio de 2015

Contenido www y embriones sobre IPv6. Region Lacnic

Buenas tardes,
  En esta oportunidad les quiero compartir un pequeño análisis sobre estadísticas de penetración de IPv6 en el mundo de contenido. En otras oportunidades (*1) hemos conversado
sobre estadísticas de penetración de IPv6 desde la perspectiva del usuario final. En lo personal me alegra mucho contar con este tipo de mediciones porque es algo que nos faltaba.
¿Qué quiere decir estadísticas de penetración de IPv6 en el mundo de contenido?Básicamente es saber cuánto contenido/servidores existe sobre IPv6, NO cuántos usuarios NI cuánto tráfico sobre IPv6 está siendo cursado. 
ProblemasEl mayor problema que se encuentra es determinar con certeza cuál contenido se encuentra en un país. Recordemos que Internet es una red globalizada, saber que donde se encuentra el "host" de un dominio es algo muy complejo. Ciertamente existen muchas técnicas pero de igual manera no son 100% confiables. Ejemplo: indicar que el dominio www.example.com.ve está en Venezuela puede ser totalmente cierto, parcialmente cierto o totalmente negativo. Para poder llevar a cabo este estudio decidimos tomar únicamente dominios con ccTLD de nuestra región.
¿Cómo se realizó este estudio?Vamos a indicarlos por pasos para visualizarlo mejor:
1) Se toma un archivo con los TOP 1 millón de dominios del mundo (*2)
2) Se toma el ccTLD de los mismos (.ar, .uy, .br, .ve, etc)
3) Del punto 2 se averigua si tienen registros AAAA en su www
4) Del punto 2 se hace un estudio para averiguar si existen "embriones
IPv6", es decir, dominios que no tienen IPv6 en su www pero si tienen host con los nombres w6, www6, ipv6, v6 + dominio
Procesamiento:
- Del archivo Majestic Million con un millón de dominios, aproximadamente 8000 tienen ccTLD de la región de Latinoamérica y Caribe.
- Posteriormente se utiliza el dominio y se buscan registros AAAA para:
www + dominio
ipv6|v6|www.ipv6|www6|ip6|w6 + dominio
Resultados:De puede apreciar lo siguiente:
1.- Para Websites con IPv6 actuales:El top 5 de los países con Websites con AAAA tenemos:


Gráfico #1. Resumen países con sitios con registros AAAA

1.- Brasil cuenta con 180 sitios que representa el 57.3% del total
2.- Colombia con 47 sitios que representa el 15% del total
3.- México con 33 sitios que representa el 10.5% del total
4.- Argentina con 10 sitios que representa el 3.2% del total
5.- Chile con 7 sitios que representa el 2.2 del total

(estadísticas para el 22 de Julio, 7709 dominios estudiados y 314 Websites con AAAA)


Gráfico #2. Resumen sitios actuales con AAAA
2.- Para Websites embriones:El top 5 de los países con Websites embriones tenemos:

Gráfico #3. Resumen países con embriones IPv6


1.- Brasil 25 (con 45.5 %)
2.- Colombia 18 (32.7%)
3.- Mexico (9.1%)
4.- Perú 2 (3.6 %)
5.- Chile 2 (3.6 %)

(estadísticas para el 22 de Julio, 7709 dominios estudiados y 55 Websites embrios encontrados)

Gráfico #4. Resumen sitios embriones IPv6


Es muy interesante apreciar que Brasil, Colombia, México y Chile se encuentran en ambos cuadros mientras que Perú y Argentina se intercambian la 4ta posición.
Los resultados pueden ser obtenidos en el sitio: http://stats.labs.lacnic.net y buscando por “Websites actuales con IPv6” y “Embriones Websites (AAAA)” en la columna de la izquierda.


Conclusión:  Primero, que nada, es una alegría observar que existen más sitios con IPv6 que embriones por nacer ( claro, de alguna manera se entiende que lo anterior tiene sentido y en realidad no quise caer en comparaciones de otras índoles).
  Segundo, se entiende que puede existir un aspecto también de idiosincrasia donde algunos países y administradores sean más cuidadosos -o menos- y no usen un URL de embriones y coloquen su sitio en v6 directamente.
  Tercero, de alguna manera podemos esperar que en un futuro consigamos que los sitios embrionarios se conviertan en sitios formales (www) con IPv6.
¿Posibles próximos pasos?- En el presente estudio se evaluó únicamente dominios listados en el TOP 1 millón de Majestic
filtrados por ccTLD de la nuestra región Latam y Caribe, se puede evaluar la manera de extender este estudio a otros listados
- Identificar si la dirección IPv6 que apunta el AAAA es de Lacnic
- Estudiar cuánto tiempo pasa un sitio embrión a un sitio formal con IPv6.

Margen de error:- Se entiende que puede existir un margen de error, un host embrión no significa que sea
necesariamente movido al www del dominio.
Tecnisismos:- Todos los scripts fueron realizados en python3 sobre Linux Ubuntu 13.04

Por:
Alejandro Acosta
Lacnic
@ITandNetworking
*1. Retrospectiva: Acceso IPv6 en la region Latinoamerica y Caribe (LAC) en: http://portalipv6.lacnic.net/retrospectiva-acceso-ipv6-en-la-region-latinoamerica-y-caribe-lac/
*2. https://majestic.com/reports/majestic-million

lunes, 17 de noviembre de 2014

$GENERATE usando registros A en BIND. Match forward y rDNS

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 resolvera a 192.168.30.X

  Seria asi:
  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 tu utilidad
 

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) (ideas para 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?)





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 por ejemplo:
     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!

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


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

  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

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!!.    

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.

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!,