Instalación del servidor DHCP, WINS, DNS, ICS, problemas comunes y soluciones durante el proceso de configuración

dhcp:

¿Cómo solucionar el problema del servidor DHCP ilegal en la LAN?

Recientemente, algunas computadoras de la empresa con frecuencia no han podido acceder al Internet Estas computadoras obtienen automáticamente direcciones IP. Sí, pero después de verificar, descubrí que la dirección de puerta de enlace que obtuvieron era incorrecta. Según el sentido común, DHCP no enviará la puerta de enlace incorrecta a la computadora cliente. Más tarde, después de usar ipconfig /release para liberar los parámetros de red obtenidos, usé ipconfig /renew para obtener la dirección de puerta de enlace real, pero la mayoría de los datos obtenidos seguían siendo incorrectos. Entonces afirmo que debe haber otros servidores DHCP en la LAN, también llamados servidores DHCP ilegales. ¿Por qué los parámetros de red asignados por el servidor DHCP real no se pueden transmitir correctamente al cliente?

Primero, comprendamos el mecanismo de servicio de DHCP:

Generalmente, habrá un servidor DHCP dentro de la empresa para proporcionar la información necesaria de los parámetros de red a las computadoras cliente, como la dirección IP, Máscara de subred, puerta de enlace, DNS y otras direcciones, en muchos casos el enrutador puede asumir esta importante tarea. Cada vez que se inicia la computadora cliente, enviará un paquete de transmisión a la red para encontrar un servidor DHCP (siempre que la computadora esté configurada para obtener automáticamente una dirección IP). El paquete de transmisión se envía aleatoriamente a la red. recibe el paquete de transmisión Enviará un mensaje de respuesta a la computadora con la dirección MAC de origen del paquete y, al mismo tiempo, extraerá una dirección IP de su propio grupo de direcciones y la asignará a la computadora.

¿Por qué los equipos cliente consideran legítimo el DHCP ilegal?

De acuerdo con el mecanismo de servicio de DHCP, el paquete de transmisión enviado por la computadora cliente después de iniciarse se enviará a todos los dispositivos en la red. No existe ninguna regla sobre si el servidor DHCP es legal o ilegal. El servidor DHCP responde primero. Las computadoras cliente tampoco tienen la capacidad de distinguir entre lo legal y lo ilegal. De esta manera, la red queda completamente interrumpida y las máquinas que normalmente pueden acceder a Internet ya no pueden conectarse a Intelnet.

Solución:

1. ipconfig /release e ipconfig /renew

Podemos resolver temporalmente este problema intentando enviar paquetes de difusión varias veces hasta que el cliente puede obtener la dirección real. Es decir, primero use ipconfig /release para liberar datos de red ilegales y luego use ipconfig /renew para intentar obtener los parámetros de red. Si aún recibe un mensaje de error, intente /release y /renew nuevamente hasta que obtenga la información correcta.

Recordatorio: este método trata los síntomas pero no la causa raíz, y no se garantiza el número de intentos repetidos. Además, cuando la concesión de DHCP expira, la computadora cliente debe buscar el servidor DHCP nuevamente. para obtener información, y la falla seguirá ocurriendo.

2. Filtre los servidores DHCP ilegales mediante el método "dominio".

Agregue el servidor DHCP legal a Active Directory (Active Directory) y utilice este método de autenticación. Detenga de manera efectiva los servidores DHCP ilegales. El principio es que un servidor DHCP que no se ha unido al dominio enviará un paquete de consulta DHCPINFORM a otros servidores DHCP en la red antes de responder a la solicitud. Si otros servidores DHCP responden, entonces este servidor DHCP no puede responder a la solicitud del cliente. es decir, un servidor DHCP que se une a un dominio en la red tiene una prioridad más alta que un servidor DHCP que no se une a un dominio. De esta manera, el DHCP ilegal no tendrá ningún efecto cuando exista DHCP legal.

Recordatorio: Aunque este método funciona bien, requiere soporte de dominio. Debe saber que para muchas pequeñas y medianas empresas, el "dominio" es excesivo para ellas. Básicamente, usar grupos de trabajo es suficiente para manejar el trabajo diario. Por lo tanto, este método funciona bien, pero no es adecuado para la situación real.

3. Bloquear puertos en el equipo de enrutamiento y conmutación

El servicio DHCP utiliza principalmente los puertos UDP 67 y 68. El paquete de respuesta del servidor DHCP utiliza el puerto 68 y el puerto 67. el cliente. Se utiliza cuando la máquina envía una solicitud.

Por lo tanto, podemos reservar el puerto 68 del servidor en el enrutador y cerrar el puerto 68 del cliente para lograr el propósito de filtrar servidores DHCP ilegales.

Recordatorio: si hay muchas computadoras, será incómodo operarlas, aumentará la carga del enrutador y afectará la velocidad de la red.

4. Descubra quién está detrás del servidor DHCP ilegal y bloquéelo

El servidor DHCP también actúa como puerta de enlace. Si obtiene la dirección de puerta de enlace ilegal, sabrá la identidad de. la dirección IP ilegal. Encuentre el nombre del host a través de ping ip y descubra la dirección MAC a través del nombre de host arp. Una vez que conozca la dirección MAC, puede bloquear la MAC en el enrutador o bloquear el puerto 68 de la MAC. O cualquier otro método servirá. Se ha encontrado el cerebro detrás de escena. Depende de usted manejarlo como quiera. Este es el cuarto método que utilizo.

------------------------------------------- ----- ----------

¿Cuál es la diferencia entre un servidor WINS y un servidor DNS?

Para muchas personas, la relación entre un El servidor WINS y el servidor DNS siguen siendo los mismos. Algo misterioso. Sin embargo, esperamos aclarar este asunto con su pregunta.

En primer lugar, DNS se refiere a "Servidor de nombres de dominio" y WINS se refiere a "Servicio de nombres de Internet de Windows". Ambos se utilizan para resolver nombres de dominio, ¡pero los métodos utilizados son completamente diferentes!

Para ayudar a ilustrar este problema, voy a utilizar un ejemplo para asegurarme de que comprende correctamente la situación de estos dos servicios.

Considere un servidor de archivos llamado "Jupiter" y los siguientes dos comandos:

Ping Jupiter.space.net

Net use * jupiter mainshare

Las dos instrucciones anteriores son muy similares. El primer comando es enviar un paquete ping (icmp echo) a nuestro servidor de archivos para confirmar que el servidor está funcionando. El segundo comando llama al mismo servidor (Júpiter) para conectarse a una carpeta compartida llamada "mainshare".

Aunque estas dos instrucciones apuntan al mismo servidor (Jupiter), la diferencia entre ellas es muy importante.

El "Ping" aquí utiliza DNS para resolver Jupiter.space.net en una dirección IP, como 204.45.12.1. El comando "net use" utiliza WINS para resolver el nombre NetBIOS "Jupiter" en una dirección IP.

Llegados a este punto, quizás te estés preguntando, ¿por qué hay dos servicios diferentes que en realidad realizan la misma tarea?

La respuesta a esta pregunta es que cada uno de los dos servicios El servicio se basa en diferentes protocolos. Simplemente funcionan de diferentes maneras.

WINS es un componente importante de la topología de red de Microsoft. En el pasado, necesitaba ejecutar un servidor WINS en su red Windows para evitar problemas de resolución de nombres de dominio. El protocolo NetBIOS (nombre de máquina de Windows) en ese momento solo podía funcionar en el protocolo de transporte NetBEUI. Si alguna vez ha utilizado Windows 95, recordará que el protocolo NetBEUI aparecía a menudo en las propiedades de su red. En las propiedades de la red, el protocolo TCP/IP también es una opción.

Actualmente, DNS reemplaza a WINS. Dado que Microsoft realizó cambios en NetBIOS que le permitieron usar la pila TCP/IP para hacer su trabajo (NetBIOS sobre TCP/IP), la mayoría de los servidores DNS pueden manejar solicitudes NetBIOS. Por eso los servidores WINS son cada vez menos comunes.

En resumen, DNS asigna nombres de host TCP/IP a direcciones IP y WINS asigna nombres de host NetBIOS a direcciones IP.

------------------------------------------- ----- -------------

DNS:

Errores de DNS comunes

1. No agregar SOA ( inicio de la autoridad) El valor de serie de RR

Esta es la razón principal de los errores de DNS. Debido a que el valor de serie no aumenta, el servidor secundario no se actualizará después de que cambien los datos del servidor primario. aspectos de SOA El servidor secundario en sí no notará el valor de SOA RR Incluso si modifica los datos en SOA RR, debe recordar cambiar el valor de serie de SOA RR. Si se descubre que el servidor secundario ha aumentado, se eliminará del principal. Realice una transferencia de zona. Después de cambiar el SOA RR, es mejor probar si el servidor secundario se ha actualizado. Actualmente existen algunas herramientas que pueden ayudar a verificar. /p>

2. Para los datos en BIND, escriba menos más adelante. Un punto menos (.)

Un punto menos parece similar, pero causa un gran problema. debe configurarse con cuidado. De lo contrario, puede ocurrir lo siguiente:

En sample.com.tw Esta capa: sample.com.tw IN NS ns.sample.com.tw representa: sample.com. .tw.sample.com.tw. EN NS ns.sample.com.sample.com.tw

-- En el nivel com.tw, ​​tal cosa sucedió

En muchos sistemas, cuando se establece una conexión, llevará mucho tiempo verificar si el nombre de dominio en el lado del cliente puede se convertirá en una dirección IP (Ejemplo: Telnet) Otro ejemplo es traceroute. Cuando esté en traceroute, los enrutadores que pasen comprobarán lo contrario. En Taiwán, debido a que no hay ninguna configuración, la pantalla se retrasará. el nombre de dominio de cada salto Otro Un ejemplo es que cuando se conecta a otro host, la fuente se registrará en el host. En este momento, también se utiliza PTR ==> Consulte RFC 1537, RFC 1713

4. Trabajo de coordinación de los administradores de DNS

Si el padre no se comunica bien con el administrador de la zona chile (puede haber varios en este nivel), es probable que ocurran dos errores: delegaciones cojas (delegación incompleta) y delegaciones faltantes (concesión perdida) En el caso de delegaciones cojas, el padre lista el servidor de nombres de un determinado dominio a continuación, pero puede haber varios de ellos y no tener toda la información de esta zona. (El significado de autoridad) si los servidores de nombres enumerados por el padre no tienen SOA (los servidores primario y secundario tendrán SOA), lo que se convierte en delegaciones faltantes. La situación más común cuando se encuentran delegaciones faltantes es que la unidad cambia la. IP, pero no notifica a la capa superior. Por supuesto, también existen algunos programas que pueden ayudar a averiguarlo.

delegaciones lame y de misión

-- De hecho, puedes encontrar un montón de mensajes "Servidor Lame en..." desde syslog. Por supuesto, también puedes desactivarlos al crear BIND. p>

5. Configuración incorrecta de resolv.conf

resolv.conf contiene un dominio local. Cuando no escribe todos los nombres de dominio, esto se agregará automáticamente y la máquina no verificará. DNS y use directamente este nombre de dominio para conectarse. Si resolv.conf tiene una entrada de nombre de dominio incorrecta, puede conectarse a varios lugares inexistentes (entonces obtendrá un error).

6. El antiguo archivo de caché raíz

El archivo de caché raíz contendrá el nombre de dominio DNS y la IP del dominio raíz. El caché raíz no cambia ni se actualiza por sí solo. El administrador debe prestar atención a si hay un nuevo servidor raíz. Si un DNS utiliza un archivo de caché raíz que es demasiado antiguo, es posible que no se encuentren algunos dominios. El archivo de caché raíz más reciente se puede obtener de ftp://rs.internic. .net/dominio/named.root.