Mostrando entradas con la etiqueta server. Mostrar todas las entradas
Mostrando entradas con la etiqueta server. 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)

The best Buy vps bitcoin from eldernode.com
Where to order pain Relief without prescription
you can buy bitcoin vps from eldernode

Host your website on the fastest servers in Chicago, USA. Hundreds of features you need. Chicago Shared Hosting Easy On-boarding & Simple Website Transfer to our Platform
카지노사이트

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



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

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


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.


jueves, 6 de enero de 2011

Descripción del log bind

Situación:
Leyendo el log de bind tengo algunas dudas

Solución:
Luego de una ardua busqueda en Google conseguí el siguiente link donde Jeremy Reed responde que significan los flag dentro del log de Bind.

Ejemplo:

05-Jan-2011 09:54:36.620 client 210.19.118.16#32784: view everyone: query: www.whatismyipv6.co IN A -EDC

Del log anterior se entiende:
Fecha
Hora
Direccion IP del cliente
Puerto utilizado por el cliente
Vista utilizado segun configuracion del cliente
Tipo de solicitud
Descripcion del objeto solicitado
- significa que no hubo solicitud de recursividad
S=Query signed
E=EDNS
D=DNSSEC Ok
C=Checking Disabled

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!

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

Solución a: Error: eth0 interface name is not allowed for R2 node when network mode is not set to none

Problema:   Containerlab devuelve un error similar: Error: eth0 interface name is not allowed for R2 node when network mode is not set to no...