Ayuda OnLine de GULiC

Anon1724

Ayuda
  • Temática: Puedes preguntarnos sobre Software Libre, Linux o GULiC. Otros temas pueden ser respondidos (o no!)
  • Acceso: De momento, se te ha asignado un nick al azar (Anon1724).Podrías usar tu propio nick registrándote ó iniciando sesión, si ya te habías registrado. En cualquier caso, si usas jabber, puedes informarte acerca de cómo entrar a esta sala con tu cliente jabber habitual, o bien entrar a la sala vía web.
  • Uso:Para ver el chat más grande, usa ésta página. Si vas a pegar textos grandes, usa nuestro pastebin. Para avisar de errores o problemas, usa nuestro track
  • Horarios: Nuestro uso horario es GMT. No te extrañe si a las 5 de la mañana no te responde nadie.
Inicio » Blogs » blog de Envite

Configurar un servidor con BIND (3)

Enviado por Envite el 9 Noviembre, 2005 - 01:36.

No se preocupen porque vean que esta serie sigue y sigue… todo se acaba Eye-wink

Hoy vamos a ver los tipos de RR que se quedaron en el tintero, comenzando, lo prometido es deuda, por la resolución DNS inversa.

Resolución inversa

Si además de ser los poseedores, o valga el caso, administradores de un dominio somos los administradores de un rango de direcciones IP somos los responsables de proporcionar resolución inversa, es decir, de informar, a quien pregunte, qué nombre se corresponde con cada IP. Es gracias a esa reslución inversa que cuando hacemos un traceroute, o un netstat, o un simple last o who, el ordenador nos da nombres DNS en lugar de direcciones IP, igual que en los logs del Apache o del servidor FTP.

Pero no hay que pensar que eso no va con nostros, ya que no se refiere sólo a las direcciones IP públicas: es un servicio que también funciona en los rangos privados, y el nombre devuelto se considera el nombre canónico correspondiente a esa IP.

$ host ulysses.gulic.org
ulysses.gulic.org has address 193.145.155.12
$ host 193.145.155.12   
12.155.145.193.in-addr.arpa domain name pointer gulic3.ulpgc.es.

Como vemos, el nombre canónico de ulysses es gulic3.ulpgc.es, lo que quiere decir que está en el rango de direcciones que administra la ULPGC. En una red privada se puede establecer el mismo servicio, ya que las direcciones las asignamos nosotros.

El árbol arpa

Aparte de los nombres de dominio de primer nivel que todo el mundo conoce como .org, .net o .es (los de dos letras correspondientes a países o territorios y los de más de dos conocidos como genéricos) hay un dominio de primer nivel dedicado a dar soporte a la infraestructura misma de la red: el dominio .arpa (el nombre viene del nombre original de Internet).

Dentro del dominio .arpa tenemos el subdominio in-addr (inverse address) cuyo objetivo es, precisamente, proporcionar la infraestructura necesaria para la resolución inversa.

Para solicitar el nombre canónico de un ordenador no se pregunta directamente por el nombre que corresponde a una dirección, sino por el nombre que corresponde a otro nombre (un poco como los RR CNAME) del árbol in-addr.arpa, como vemos en el ejemplo de arriba: este nombre se compone poniendo los números de la dirección IP en orden inverso y añadiendo al final .in-addr.arpa para poner los nombres más generales más cerca de la raíz.

Así, 12.155.145.193.in-addr.arpa es un subdominio de 155.145.193.in-addr.arpa que corresponde a todas las direcciones 193.145.155.0-193.145.155.255 y sucesivamente.

Lo mismo en una red privada: si hemos decidido utilizar la red 192.168.0.0/24 en casa, deberíamos dar cobertura al subárbol 0.168.192.in-addr.arpa.

Todo el trabajo se hace mediante un fichero de zona igual que los de la entrega anterior, sólo que en vez de registros A o registros CNAME utilizamos registros PTR:

;Fichero de zona inversa para 193.145.155.0/24

$TTL 1200

155.145.193.in-addr.arpa. IN SOA ns.ulpgc.es. hostmaster.ulpgc.es. (
                                 2005110815
                                 28800
                                 7200
                                 604800
                                 86400 )

@ IN NS  ns.ibn.ulpgc.es.
@    NS  ns.ulpgc.es.
@    NS  ns2.ibn.ulpgc.es.
@    NS  ns2.ulpgc.es.
@    NS  sun.rediris.es.
@    NS  chico.rediris.es.

  2 IN PTR  SERVICIOSEXTERNOS-RC1.red.ulpgc.es.
  3    PTR  SERVICIOSEXTERNOS-RC2.red.ulpgc.es.
  4    PTR  osl.ulpgc.es.
  7    PTR  arbitros2.ulpgc.es.
  8    PTR  latienda.sitie.ulpgc.es.
  9    PTR  arbitros.ulpgc.es.
 10    PTR  gulic.ulpgc.es.
 11    PTR  gulic2.ulpgc.es.
 12    PTR  gulic3.ulpgc.es.
 13    PTR  SERVICIOSEXTERNOS-RC3.red.ulpgc.es.
 14    PTR  SERVICIOSEXTERNOS-RC4.red.ulpgc.es.
 18    PTR  arq.cda.ulpgc.es.
 19    PTR  arucas.cda.ulpgc.es.
 20    PTR  tafira2.cda.ulpgc.es.
 21    PTR  tomas2.sic.ulpgc.es.
 27    PTR  ARQ-ARQUITECTURAPUB-RC1.red.ulpgc.es.
 28    PTR  ARQ-ARQUITECTURAPUB-RC2.red.ulpgc.es.
 29    PTR  ARQ-ARQUITECTURAPUB-RC3.red.ulpgc.es.
 30    PTR  ARQ-ARQUITECTURAPUB-RC4.red.ulpgc.es.
 34    PTR  preciemar.ccbb.ulpgc.es.
 35    PTR  vpnseas1.ccbb.ulpgc.es.
 36    PTR  vpnseas2.ccbb.ulpgc.es.
 37    PTR  q115portatil.ccbb.ulpgc.es.
 38    PTR  edutecan.ccbb.ulpgc.es.
 49    PTR  CCBB-CCBBPUB-HSRP.red.ulpgc.es.
 50    PTR  tindaya.ccbb.ulpgc.es.
 51    PTR  zeus.ccbb.ulpgc.es.
 52    PTR  ciemar.ccbb.ulpgc.es.
 53    PTR  eros.ccbb.ulpgc.es.
 54    PTR  capo.ccbb.ulpgc.es.
 56    PTR  capo2.ccbb.ulpgc.es.
 57    PTR  oceanchem2.ccbb.ulpgc.es.
 58    PTR  b203-3.ccbb.ulpgc.es.
 59    PTR  CCBB-CCBBPUB-RC1.red.ulpgc.es.
 60    PTR  CCBB-CCBBPUB-RC2.red.ulpgc.es.
 61    PTR  CCBB-CCBBPUB-RC3.red.ulpgc.es.
 62    PTR  CCBB-CCBBPUB-RC4.red.ulpgc.es.
 65    PTR  POL-CIDIAPUB-HSRP.red.ulpgc.es.
 66    PTR  servidor.cidia.ulpgc.es.
 75    PTR  POL-CIDIAPUB-RC1.red.ulpgc.es.
 76    PTR  POL-CIDIAPUB-RC2.red.ulpgc.es.
 77    PTR  POL-CIDIAPUB-RC3.red.ulpgc.es.
 78    PTR  POL-CIDIAPUB-RC4.red.ulpgc.es.
 81    PTR  POL-IUMAPUB-HSRP.red.ulpgc.es.
 91    PTR  POL-IUMAPUB-RC1.red.ulpgc.es.
 92    PTR  POL-IUMAPUB-RC2.red.ulpgc.es.
 93    PTR  POL-IUMAPUB-RC3.red.ulpgc.es.
 94    PTR  POL-IUMAPUB-RC4.red.ulpgc.es.
 97    PTR  EMPRE-BIBPUB-HSRP.red.ulpgc.es.
 98    PTR  tamadaba.biblioteca.ulpgc.es.
 99    PTR  bdigital.biblioteca.ulpgc.es.
100    PTR  bentayga.biblioteca.ulpgc.es.
101    PTR  machi.biblioteca.ulpgc.es.
102    PTR  bdigitalm.biblioteca.ulpgc.es.
103    PTR  ansite.biblioteca.ulpgc.es.
107    PTR  EMPRE-BIBPUB-RC1.red.ulpgc.es.
108    PTR  EMPRE-BIBPUB-RC2.red.ulpgc.es.
109    PTR  EMPRE-BIBPUB-RC3.red.ulpgc.es.
110    PTR  EMPRE-BIBPUB-RC4.red.ulpgc.es.
130    PTR  becario-docu.sic.ulpgc.es.
133    PTR  alojamiento.ulpgc.es.
145    PTR  cisco-vet-155-seg9.red.ulpgc.es.
146    PTR  sasrv.vet.ulpgc.es.
148    PTR  iusa-srw.vet.ulpgc.es.
162    PTR  geminis.dma.ulpgc.es.
178    PTR  cicei.sitie.ulpgc.es.
179    PTR  cief.sitie.ulpgc.es.
180    PTR  ingb.sitie.ulpgc.es.
181    PTR  osl.sitie.ulpgc.es.
182    PTR  novellpruebas.sitie.ulpgc.es.
187    PTR  ING-INGENIERIAPUB-RC1.red.ulpgc.es.
188    PTR  ING-INGENIERIAPUB-RC2.red.ulpgc.es.
189    PTR  ING-INGENIERIAPUB-RC3.red.ulpgc.es.
190    PTR  ING-INGENIERIAPUB-RC4.red.ulpgc.es.
209    PTR  HUMANIDADESPUB-HSRP.red.ulpgc.es.
212    PTR  colmillo.humanidades.ulpgc.es.
213    PTR  hd118a.humanidades.ulpgc.es.
219    PTR  HUMANIDADESPUB-RC1.red.ulpgc.es.
220    PTR  HUMANIDADESPUB-RC2.red.ulpgc.es.
221    PTR  HUMANIDADESPUB-RC3.red.ulpgc.es.
222    PTR  HUMANIDADESPUB-RC4.red.ulpgc.es.
225    PTR  POL-IUCTCPUB-HSRP.red.ulpgc.es.
227    PTR  iuctc.ulpgc.es.
228    PTR  ccpc.ciber.ulpgc.es.
229    PTR  mcculloch.ciber.ulpgc.es.
230    PTR  pcjcarlos.ciber.ulpgc.es.
237    PTR  RouterCore1-155-seg14.red.ulpgc.es.
238    PTR  RouterCore2-155-seg14.red.ulpgc.es.

¿Y si administro una red más grande?

La estructura del árbol in-addr.arpa hace que se pueda dar servicio a una red compuesta de varias redes /24 creando un fichero de zona para cada una, o a una red /16 con, simplemente, quitar un elemento del nombre de dominio.

¿Y si administro una red más pequeña?

La respuesta típica sería que no se puede, que es el administrador de la red /24 el que tiene que hacerlo, y que tienes que ponerte de acuerdo con él y, en todo caso, mandarle los cambios para que él los incluya en el fichero.

Pero las cosas no son tan crudas.

Ya que andamos trasteando con DNS, se pueden utilizar las herramientas propias de DNS para solucionar el problema. Veamoslo con un ejemplo sacado del RFC 2317:

Supongamos que administramos la red 192.0.2.0/24 y hemos asignado subredes de la siguiente manera:

192.0.2.0/25 a la organización A
192.0.2.128/26 a la organización B
192.0.2.192/26 a la organización C

Normalmente habría que usar un fichero de zona inverso único como:

$ORIGIN 2.0.192.in-addr.arpa.
;
1               PTR     host1.A.domain.
2               PTR     host2.A.domain.
3               PTR     host3.A.domain.
;
129             PTR     host1.B.domain.
130             PTR     host2.B.domain.
131             PTR     host3.B.domain.
;
193             PTR     host1.C.domain.
194             PTR     host2.C.domain.
195             PTR     host3.C.domain.

Pero lo vamos a resolver utilizando registros de tipo CNAME:

$ORIGIN 2.0.192.in-addr.arpa.
@       IN      SOA     my-ns.my.domain. hostmaster.my.domain. (...)

;  <<0-127>> /25
0/25            NS      ns.A.domain.

1               CNAME   1.0/25.2.0.192.in-addr.arpa.
 ;Esto mapea 1.2.0.192.in-addr.arpa (basta fijarse en el $ORIGIN)
2               CNAME   2.0/25 ; Aquí acortamos gracias también al $ORIGIN
3               CNAME   3.0/25

;  <<128-191>> /26
128/26          NS      ns.B.domain.

129             CNAME   129.128/26
130             CNAME   130.128/26
131             CNAME   131.128/26

;  <<192-255>> /26
192/26          NS      ns.C.domain.

193             CNAME   193.192/26
194             CNAME   194.192/26
195             CNAME   195.192/26

Y luego cada administrador de las organizaciones A, B y C crea ficheros como estos:
Organización A:

$ORIGIN 0/25.2.0.192.in-addr.arpa.
@       IN      SOA     ns.A.domain. hostmaster.A.domain. (...)
@               NS      ns.A.domain.

1               PTR     host1.A.domain.
2               PTR     host2.A.domain.
3               PTR     host3.A.domain.

Organización B:

$ORIGIN 128/26.2.0.192.in-addr.arpa.
@       IN      SOA     ns.B.domain. hostmaster.B.domain. (...)
@               NS      ns.B.domain.

129             PTR     host1.B.domain.
130             PTR     host2.B.domain.
131             PTR     host3.B.domain.

Organización C:

$ORIGIN 192/26.2.0.192.in-addr.arpa.
@       IN      SOA     ns.C.domain. hostmaster.C.domain. (...)
@               NS      ns.C.domain.

193             PTR     host1.C.domain.
194             PTR     host2.C.domain.
195             PTR     host3.C.domain.

Pero por si alguien argumenta que la barra no es un carácter válido (que sí lo es, porque esto no son nombres de host), se puede utilizar cualquier otro en su lugar, como el guión.

Por otro lado, un CNAME puede apuntar fuera del árbol in-addr.arpa con lo que se facilita aún más el trabajo de los administradores de las organizaciones A, B y C:

1.2.0.192.in-addr.arpa. IN CNAME 1.A.domain.

Y luego podemos poner juntos:

1.A.domain. IN PTR host1.A.domain.
host1.A.domain IN A 192.0.2.1

$GENERATE

Justo en la creación de ficheros repetitivos como estos es de utilidad la directiva $GENERATE que mencionamos en la entrega anterior.

$GENERATE se utiliza indicando un esqueleto de RR a generar, indicando un rango y sustituyéndolo con $:

$GENERATE 5-8 host$.dominio. A 192.168.0.$

se convierte en:

host5.dominio. A 192.168.0.5
host6.dominio. A 192.168.0.6
host7.dominio. A 192.168.0.7
host8.dominio. A 192.168.0.8

El rango puede ser del tipo comienzo-final o comienzo-final/paso, y los tres valores deben ser positivos. Si no se especifica el paso se toma, como se puede imaginar, que es 1.

El tipo de RR es obligatorio ponerlo, y sólo puede ser PTR, CNAME, DNAME, A, AAAA o NS.

Si se quiere poner un signo “$” en el resultado debe hacerse con \$ (aunque por compatibilidad con versiones anteriores de BIND se puede usar $$).

Se pueden añadir una clase y un TTL como en los RR normales.

El resultado de $ se puede modificar sumándole o restándole una cantidad fija y/o representándolo en decimal, octal u hexadecimal. Para ello se utilizan llaves: ${desplazamiento,tamaño,base}:

$GENERATE 2-3 ${9}.155.145.193.in-addr.arpa.    PTR  gulic$.ulpgc.es.

se convierte en:

11.155.145.193.in-addr.arpa.    PTR  gulic2.ulpgc.es.
12.155.145.193.in-addr.arpa.    PTR  gulic3.ulpgc.es.

y

$ORIGIN midominio.
$GENERATE 2-3 ${0,4}    A  192.168.0.$

se convierte en:

0002.midominio.    A  192.168.0.2
0003.midominio.    A  192.168.0.2

y finalmente

$GENERATE 1-4 host${7,2,X}.midominio. A 192.168.0.${100}

se convierte en:

host08.midominio. A 192.168.0.101
host09.midominio. A 192.168.0.102
host0A.midominio. A 192.168.0.103
host0B.midominio. A 192.168.0.104

con lo que vemos que tenemos, además de la conversión “d” (decimal) por defecto, las conversiones “o” (octal), “x” (hexadecimal con letras minúsculas) y “X” (hexadecimal con letras mayúsculas) para usar como base.

Con esto, el fichero de zona inversa en el caso del ejemplo anterior es algo tan sencillo como:

$ORIGIN 2.0.192.in-addr.arpa.
@       IN      SOA     my-ns.my.domain. hostmaster.my.domain. (...)

;  <<0-127>> /25
0/25            NS      ns.A.domain.

$GENERATE 1-126 $ CNAME    $.0/25

;  <<128-191>> /26
128/26          NS      ns.B.domain.

$GENERATE 129-190 $ CNAME    $.128/26

;  <<192-255>> /26
192/26          NS      ns.C.domain.

$GENERATE 193-254 $ CNAME    $.192/26

NOTA: $GENERATE no es parte estándar del sistema DNS, sino una extensión propia de BIND.

Otros tipos de RR

Pues aparte de los tipos ya vistos (SOA, NS, A, AAAA, MX, CNAME y PTR) hay otros tipos válidos definidos en distintos RFC:

A6 Dirección IPv6 que puede ser parcial (un sufijo) e indicar dónde encontrar el resto de la dirección. Experimental. RFC 2874.

AFSDB Servidores de bases de datos AFS. Experimental. RFC 1183.

APL “Address Prefix List”. Experimental. RFC 3123.

CERT Certificado digital. RFC 2538.

DNAME Reemplaza el nombre de dominio especificado con otro nombre en el que buscar, haciendo un alias de una rama completa del árbol DNS en vez de un nombre simple como CNAME. RFC 2672.

GPOS Especifica la posición global. Superado por LOC.

HINFO Identifica el tipo de CPU y el Sistema Operativo utilizados. RFC 1035.

ISDN Representación de direcciones RDSI. Experimental. RFC 1183.

KEY Almacena una clave pública asociada a un nombre DNS. RFC 2535.

KX Servidor de claves para este nombre DNS. RFC 2230.

LOC Para información GPS. Experimental. RFC 1876.

NAPTR Puntero a la autoridad DNS. RFC 2915.

NSAP Un punto de acceso a servicios de red. RFC 1706.

NXT Se utiliza en DNSSEC para indicar de manera segura que los RR con un nombre determinado no existen en una zona e indicar qué tipos sí existen. RFC 2535.

PX Mapea entre direcciones RFC 822 y X.400. RFC 2163.

RP Información sobre las personas responsables de un dominio. Experimental. RFC 1183.

RT Enlace a través de rutas para equipos que no tienen su propia dirección directa de red de área amplia (WAN). Experimental. RFC 1183.

SIG (“signature”) Contiene datos autentificados en DNSSEC. RFC 2535.

SRV Informa sobre servicios de red bien conocidos (reemplaza a WKS). RFC 2782.

TXT Registros de texto. RFC 1035.

WKS Informa sobre servicios de red bien conocidos. Histórico.

X25 Direcciones de redes X.25. Experimental. RFC 1183.

En la próxima entrega

Sabiendo ya crear ficheros de zona, en la próxima entrega veremos el resto de la configuración de un servidor BIND sencillo.

»

Tengo algunas dudas

Enviado por alfonso el 27 Diciembre, 2005 - 01:17.

Veo que se puede instalar un servidor de nombres en casa sin tener que pagar a ningún proveedor para que te aloje en su servidor de nombres y te lo apunte a tu máquina.

¿Quién informa a los ROOT-SERVERS o a los servidores por encima de uno, como llegar a ti? ¿Tu propio servidor de Nombres?

¿Y que pasa si te lo configuras como microsoft.com o dominioinventado.com?

¿Has de abrir/redireccionar algún puerto en tu router?

Me imagino que tengo que tener un IP fija, pero ¿Y si tengo una dinámica con un dominio no-ip apuntando a mi máquina, puedo hacerlo?

Disculpa mi ignorancia. Gracias de antemano por tu respuesta.
Felices Fiestas

»

Por delegación

Enviado por aplatanado el 27 Diciembre, 2005 - 08:48.

Los root servers tienen delegado cada dominio .es, .com, .uk, a la entidad de gestión correspondiente. Así que cuando los consultas son ellos los que te dicen “pregunta al servidor de nombres xxx que es el que gestiona el dominio que pides”.

A su vez los servidores de nombre que gestionan el dominio, por ejemplo, .es tienen delegado los dominios de las diversos organismos y empresas. Es decir el servidor de nombres del dominio .es te dice “pregunta al servidor de nombres yyy que es el que gestiona el domino ola.es”. Y así sucesivamente hasta llegas al servidor que tiene la entrada A con la IP de la máquina que buscas.

Por lo tanto para tener un dominio es necesario comprarlo. Puedes montar tu propio servidor DNS pero para que alguien lo encuentre el dominio que quieres debe ser te delegado y apuntar a tu servidor.
Hecho esto podrás crear el número de entras de quieras en tu servidor. Incluso podrás crear subdominios y delegarlos a otras máquinas.

Lo que nadie te impide es montar un servidor de nombres de dominio para tu red interna. O montar tu servidor de nombres y que tus amigos lo utilicen, de forma de que puedes crear una “internet” paralela donde microsoft.com no va a la página que debería. Pero todo eso solo te afectaría a ti y los que usen tu servidor. Si no entras en la jerarquía mundial del DNS, tu servidor no existe para el resto del mundo.

El puerto de comunicación del DNS es el 53 por TCP y UDP. Si quieres montar un servidor al mundo exterior debes tenerlo abierto y redireccionado a tu servidor.

¿Qué es eso dominio no-ip apuntando hacia ti?

—
May the Free Software Force be with you…

»

DNS dinámicos

Enviado por amd77 el 27 Diciembre, 2005 - 10:38.

no-ip es http://www.no-ip.com/ muy parecido a dyndns y otros proveedores que te asocian una ip dinámica con un nombre de subdominio estilo micasa.dyndns.org.

Estos proveedores tienen el servicio “especial” (pagando) de que con el mismo programita con el que asignas tu ip dinamica a loquesea.dyndns.com, si les transfieres el dominio a ellos y les pagas, puedes tambien asignar tu ip dinámica a loquesea.com y gestionar los subdominios *.loquesea.com en tu servidor de nombres.

A esto le veo yo dos problemas:

  • El primero es el bajo tiempo de refresco. Para las entradas de *.dyndns.org por ejemplo, ese tiempo es de 60 segundos… eso significa que tus peticiones caducan muy rápido y tienes que estar consultando al padre (dyndns.org) prácticamente siempre. Esto es lógico si tu ip es dinámica, pero no es el comportamiento tradicional de un dns, donde ese número es de 6-24 horas para que se pueda cachear bien en el resto de servidores dns (si cae dyndns.org te quedaste sind dominios).

  • El segundo es que si te cambian la ip tienes que reconfigurar las zonas de tu bind. Y como no vas a estar pendiente siempre, tendrás que automatizarlo. Esto es un problema meramente técnico que se arregla con algo de scripting.

»

Problema con reverse no funciona

Enviado por caplinux el 12 Abril, 2007 - 02:53.

Hola esta muy bueno tu documento pero tengo una pregunta como hago para hacer lo siguiente:

Tengo una red 192.168.1.0/20

quiero hacer un solo archivo donde yo agregue todos los reverses pero me gustaria una opinion tuya en el named.conf lo coloque asi

zone “0/20.0.168.192.in-addr.arpa” {
type master;
file “0.168.192.in-addr.arpa.zone”;
notify yes;
};

0.168.192.in-addr.arpa.zone
$TTL 2D
…..
@ IN NS ns1.caplinux.com

1 IN PTR ns1.caplinux.com

; Gen para 192.168.1.0
$GENERATE 2-253 $.1 PTR host$-red-1.caplinux.com.

; Gen para 192.168.2.0
$GENERATE 2-253 $.2 PTR host$-red-1.caplinux.com.
….

he intentado esto pero la verdad no me funciona, he pensado que pueda ser problema de la mascara /20 que es muy grande.

Gracias

»

Un par de detalles

Enviado por Envite el 16 Abril, 2007 - 16:39.

A ver…

192.168.1.0/20 quiere decir que hay 20 bits fijos en la máscara.

Veámoslo detalladamente:

192     .168    .1       .0
11000000.1010100.00000001.00000000
RED-----------------/\--------HOST

Como ves, el 1 del tercer octeto queda en la zona de host, no en la de red. Es decir, no puede existir una red “192.168.1.0/20”, es imposible. La red representada es 192.168.0.0/20, que llega desde:

192     .168    .0       .0
11000000.1010100.00000000.00000000
RED-----------------/\--------HOST

hasta

192     .168    .15      .255
11000000.1010100.00001111.11111111
RED-----------------/\--------HOST

Aparte de que tienes la red mal, deberías comprobar si las zonas están bien delegadas.

»

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.