Esta noche he estado leyendo un poco sobre cómo configurar mejor nuestra red escolar para la conectividad a Internet. Funciona tal como está, pero de vez en cuando hay problemas en el acceso del cliente/servidor a Internet. (nota: Sonicwall siempre ve Internet)
Mi configuración como es:
Internet---Sonicwall---Switch administrado---Servidor Win 2k8 r2 | Clientes e impresores
El muro sónico
- Zona LAN con una IP en nuestro rango de IP
- Zona WAN con IP estática asignada por el ISP y DNS configurado en Google DNS y el DNS del ISP como respaldo
El servidor de Windows (solo un servidor de archivos interno)
- Directorio Activo
- DNS (establecido en 127.0.0.1)
- DHCP dinámicamente para un rango pequeño de invitados (teléfonos),
- DHCP estáticamente para dispositivos y clientes de estudiantes y profesores (para fines de filtrado)
Los clientes
- Puerta de enlace configurada en Sonicwall IP
- DNS configurado en IP del servidor (en algunos sistemas Win8 tuve que configurar un DNS alternativo en 8.8.8.8 para la conectividad a Internet.
Entonces, a las preguntas:
Por lo que leí esta noche parece que debería haber:
- La WAN de Sonicwall mirando hacia adentro, hacia la IP del servidor para DNS
- El servidor configurado para tener reenvío para mirar hacia el DNS de Google/ISP
- El DNS del cliente configurado en IP del servidor y la puerta de enlace en IP de Sonicwall
¿Alguien puede verificar esto? Estoy confundido. Si Sonicwall busca DNS de Internet en el servidor, ¿mis clientes A) atascarán el servidor y B) no tendrán Internet cuando el servidor esté apagado?
Si esta no es una buena práctica, ¿cuál es entonces? ¿Ya lo estoy haciendo bien? ¿El DNS del cliente debería mirar al servidor Y al ISP?
¡Gracias! cris
Respuesta1
Dado que el servidor ejecuta Active Directory/DNS, los clientesDEBEtener su DNS configurado en el servidor para una resolución/conectividad de dominio adecuada con los recursos internos.
La clave es tener configurado el servicio DNS del servidor para reenviar todas las consultas no locales a un solucionador externo (como Google [8.8.8.8; 8.8.4.4]). El tráfico DNS es tan pequeño que no debería tener ningún efecto perceptible en su servidor a menos que tenga el caché configurado demasiado bajo.
La pila de red del servidor debe configurarse para buscar en 127.0.0.1 (o su dirección local) la resolución DNS y el servicio debe configurarse con reenviadores.
En lo que respecta a Sonicwall, puedes configurarlo de cualquier manera. Si desea que Sonicwall pueda resolver FQDN internos y externos, deberá utilizar su servidor local para la resolución. Si solo necesita externo, configúrelo en los solucionadores de su ISP o en los de Google.
Respuesta2
Como ya ha indicado JuxVP, cualquier cliente de Windows unido a un dominiodebetener su DNS configurado en el servidor AD; de lo contrario, muchos servicios fallarán, especialmente la autenticación. Todos los demás clientes internos deben tener su DNS configurado en el servidor AD si desea que resuelvan nombres internos.
Además, los clientes de Windows unidos a un dominiono debetenga otros servidores DNS en la lista que no puedan resolver consultas de AD porque Windows no garantiza el orden de búsqueda. Ej: si tiene la siguiente configuración en un cliente:
DNS1: 192.168.10.10 (AD server)
DNS2: 8.8.8.8 (Google DNS)
entonces es probable que tenga problemas de autenticación, bloqueos inusuales u otros problemas de comunicación. Esto se debe a que el cliente puede consultar el DNS de Google adserver.domain.localy el servidor de Google responderá does not existen lugar de un tiempo de espera. El cliente sólo probará con el otro servidor si el primero no responde. Si el cliente recibe una does not existrespuesta, se dará por vencido y la búsqueda fallará.
Respuesta3
- El servidor DNS de Sonicwall debe configurarse para la dirección IP DNS de su ISP.
- Su servidor (es decir, servidor DNS de dominio) se puede configurar con reenviadores al DNS de Google.
- El DNS del punto final debe configurarse para el servidor DNS del dominio.
Respuesta4
Dado que trabaja en el sector educativo, le recomiendo configurar su servidor DNS interno para reenviar todas las solicitudes a OpenDNS. Ofrecen planes especiales solo para K-12 para cumplir con el cumplimiento de CIPA [0]. También ofrecen protección contra malware donde se bloquearán las solicitudes de recursos nefastos.
Con lo anterior configurado, configure cada host/dispositivo/etc. en su red para usar su servidor DNS interno. Hacerlo garantizará que sus clientes se conecten exitosamente entre sí internamente y es especialmente importante cuando se ejecuta Microsoft Active Directory.
A continuación, configure todas las ACL del enrutador y las reglas de firewall para permitir solo consultas DNS salientes desde su servidor DNS interno a servidores OpenDNS. El beneficio de esto es que algunos programas maliciosos intentarán realizar consultas DNS directamente a servidores de nombres públicos. Esta configuración garantiza que la solicitud pasará por sus servidores y, en última instancia, por OpenDNS, donde con suerte será detectada. Cualquier host que no utilice el servidor DNS interno (registros de caída del firewall) debe ser investigado por mala configuración o malware, ya que esto podría ser un indicador de compromiso.
Finalmente, implemente ACL del enrutador y/o reglas de firewall para bloquear el acceso a su servidor DNS desde la Internet pública.
[0]https://www.opendns.com/enterprise-security/solutions/k-12/