NetWorker depende de la resolución de nombres. Si la resolución de nombres no es correcta y es completamente coherente, pueden surgir problemas en muchas de las operaciones de NetWorker. Dado que NetWorker gestiona datos potencialmente confidenciales, debe garantizar las identidades de los hosts con los que interactúa por diversos medios.
Cualquier cantidad de síntomas en NetWorker pueden ser el resultado de imperfecciones en la resolución de nombres en NetWorker:
- Mensajes de error que indican problemas de búsqueda de nombres hacia delante o hacia atrás.
- Incapacidad para sondear clientes durante el respaldo.
- Incapacidad de los clientes para guardar manualmente en el servidor o recuperar.
- Problemas con la clonación o el acceso a los dispositivos del nodo de almacenamiento.
- Problemas de navegación o registro de la base de datos de medios.
- El servidor o el nodo de almacenamiento dejan de responder durante el inicio o durante el transcurso del funcionamiento normal.
- Directorios de índice anidados o con nombre erróneo.
- Errores de cliente configurados erróneamente.
La resolución de nombres se produce mediante varios mecanismos y en varios niveles:
- Caché de nombres de NetWorker
- Caché de resolución de host local
- Entradas de archivos de hosts locales
- Búsquedas de servidores DNS
Metodología de resolución de nombres
1. Almacenamiento en caché de NetWorker: NetWorker mantiene una caché de nombres interna y, en ocasiones, no refleja los cambios ambientales realizados para corregir problemas de resolución de nombres sin reiniciar los servicios. NetWorker también tiene un campo configurable que es global para todas las instancias del cliente llamado "Alias", que debe reflejar todos los nombres que se pueden resolver para esa instancia de cliente a fin de evitar problemas de varios tipos. Si hay un nombre requerido presente en la caché interna de NetWorker, se utiliza desde allí y no se consulta la caché de resolución del host. El demonio del servidor NetWorker (nsrd) tiene la capacidad de volcar su caché de nombres resueltos en daemon.raw, vaciar el caché o vaciar y volver a resolver los nombres:
- dbgcommand -n nsrd PrintDnsCache=1 (volcado a daemon.raw)
- dbgcommand -n nsrd FlushDnsCache=1 (vaciado)
- dbgcommand -n nsrd FlushDnsCache=9 (vaciar y resolver)
- Para los comandos anteriores, se puede utilizar "-n process name" o "-p PID". Para utilizar el PID, primero deberá ejecutar otros comandos para obtener el PID; por ejemplo, "ps -ef | grep nsr" (Linux) o "tasklist | findstr nsr" (Windows)
2. Caché de resolución: Todos los hosts y los sistemas operativos tienen una caché de resolución local para ayudar a la resolución y la velocidad de los hosts sin depender de archivos de hosts o servidores DNS. Esta caché se comprueba a continuación según las reglas normales de resolución de nombres del sistema operativo y, si el registro de host existe (incluso si es antiguo o incorrecto), se utiliza antes de consultar cualquier otro origen de datos. Las entradas de caché de resolución se ingresan en la caché en el primer intento de resolución "correcto" y permanecen durante una cantidad predeterminada de tiempo. Algunos sistemas operativos pueden mostrar el contenido de la caché de resolución (por ejemplo, los hosts de Windows pueden ejecutar ipconfig/displaydns) y todos tienen un mecanismo para borrarlo o vaciarlo por la fuerza:
- Vaciar DNS en Linux puede variar según la distribución de Linux y los paquetes instalados; consulte la documentación del proveedor.
- Windows: ipconfig/flushdns
3. Archivos de hosts: El mecanismo heredado para la resolución de hosts es ingresar explícitamente la dirección IP, seguida de los nombres que se desean resolver en esa dirección, en líneas separadas, delimitadas por un espacio en blanco. Esto se comprueba antes de DNS de manera predeterminada en Windows. En Linux, el orden de origen de resolución generalmente se puede configurar en /etc/nsswitch.conf o /etc/netsvc.conf. Los archivos de hosts solo se analizan para la primera entrada coincidente que se consulta; por lo tanto, no se encontrará ninguna segunda instancia de una dirección IP o un nombre de host, corta o larga, cuando se intenten resolver nombres. Cada nombre o IP solo debe aparecer una vez, ya que todos los nombres se deben ingresar en la misma línea de la dirección IP correspondiente.
- Unix/Linux: /etc/hosts
- Windows: %systemroot%\System32\drivers\etc\hosts
NOTA: Los archivos de hosts pueden dañarse, como cualquier otro archivo: cuando tenga dudas, cambie el nombre del archivo de hosts existente, cree el nuevo, borre la caché de resolución y vuelva a intentarlo.
4. Resolución de reenvío: Para comunicarse con un host externo cuando se proporciona el nombre, un host debe encontrar la dirección IP de los hosts ajenos para que se generen comunicaciones TCP/IP. Cuando se usa DNS, se debe realizar la consulta para ese nombre de host en la zona de búsqueda directa para recuperar la dirección IP. Se pueden configurar varios hosts DNS para que un cliente lo utilice; en sistemas Windows, utilice ipconfig/all para obtener nombres DNS; en sistemas operativos Linux/UNIX, /etc/resolv.conf generalmente lleva el orden del servidor DNS. nslookup es la herramienta más común para consultar DNS y existe en todas las plataformas, pero se utiliza con frecuencia de manera incorrecta; para consultar la zona de reenvío:
- Ejecute nslookup sin argumentos para ingresar al indicador interactivo.
- Ingrese la iteración del nombre que desea buscar y presione Intro para recuperar el registro de reenvío desde el servidor DNS al que se conectó.
- Ingrese el mismo nombre dos veces más para ver si el registro de nombre realiza operaciones por turnos de forma silenciosa entre diferentes hosts o devuelve los mismos datos.
- Repita el mismo proceso para cualquier instancia de cualquier nombre al que el host pueda ser llamado por otros hosts o que se considere para la misma dirección IP.
- Repita el mismo proceso para cualquier otro servidor DNS en el que el host esté configurado para utilizar potencialmente ingresando al servidor next_dns_server.
NOTA: Todos los registros que se devuelven deben ser coherentes entre ellos y coherentes con lo que el administrador entiende que es correcto; y todos los nombres conocidos deben tenerse en cuenta y verificarse.
5. Resolución inversa: Para comunicarse con un host externo cuando se proporciona la dirección IP, es posible que el host deba encontrar el nombre del host; cuando se usa DNS, la consulta se realiza en la zona de búsqueda inversa para buscar el nombre de host de la dirección IP en cuestión. Una vez más, esto se utiliza con frecuencia, ya que ingresar nslookup IP_Address o incluso ingresar la dirección IP en nslookup no consultará la zona de búsqueda inversa:
- Ejecute nslookup sin argumentos para ingresar al indicador interactivo.
- Ingrese set q=ptr para cambiar el tipo de consulta a la zona inversa.
- Ingrese la dirección IP para revertir la resolución y presione Intro.
- Asegúrese de que el nombre que se muestra en el registro inverso coincida con el nombre/IP del registro de reenvío.
[root@linux_a~]# nslookup linux_a
Server: 1.2.3.4
Address: 1.2.3.4#53
Name: linux_a.domain.com
Address: 5.6.7.8
[root@linux_a~]# nslookup 5.6.7.8
Server: 1.2.3.4
Address: 1.2.3.4#53
Name: linux_a.domain.com
Address: 5.6.7.8
[root@linux_a~]# nslookup
> set q=ptr
> 5.6.7.8
Server: 1.2.3.4
Address: 1.2.3.4#53
Non-authoritative answer:
8.7.6.5.in-addr.arpa name = linux_a.domain.com.
En el ejemplo anterior, está claro que la ejecución de nslookup de manera no activa nunca consulta la zona de búsqueda inversa.
NOTA: NetWorker depende en gran medida de la resolución inversa perfecta y coherente, así como de la resolución de avance estándar. Esto es parte de su proceso de autorización y está diseñado de esta manera intencionalmente para evitar la suplantación de propiedad intelectual u otros tipos de ataques destinados a robar datos de respaldo.
Solución
Se debe garantizar que todos los hosts de NetWorker tengan una resolución de nombres coherente, tanto hacia delante como hacia atrás, para cualquier host con el que se comuniquen (que varía según la función de la zona de datos). Es fundamental que los administradores de NetWorker se aseguren de que cualquier problema de resolución de host se aborde de inmediato y por completo.
Cuando solucione problemas de resolución de nombres o para descartarlos en su zona de datos de NetWorker:
1. Encuentre todos los hosts involucrados en la operación fallida: servidor, clientes y posiblemente nodos de almacenamiento, etc.
2. Para cada uno, determine las direcciones IP configuradas localmente y todos los nombres esperados que puedan resolverse para esas IP.
3. Configure todos los hosts para usar el archivo de hosts antes de DNS para la resolución de hosts.
4. Al comienzo del archivo hosts de un host, configure una sola entrada para cada IP, con cada nombre que corresponda en la misma línea.
5. Copie esas líneas exactamente desde el primer host a los archivos de hosts de los otros hosts involucrados.
6. Edite los objetos del cliente NetWorker para que los alias correspondan correctamente a las IP deseadas.
7. Apague NetWorker en todos los hosts involucrados
8. Borre la caché de resolución en cada host utilizando el mecanismo apropiado del sistema operativo
9. Reinicie NetWorker e intente la operación problemática nuevamente.
Para probar el nombre que está resolviendo un host determinado, utilice esta prueba:
1. Desde el primer host de NetWorker (por ejemplo, el cliente), conéctese al segundo (por ejemplo, el servidor) mediante
nsradmin -s remote_host -p nsrexec; deje la sesión abierta
2. En el mismo host, determine el proceso para nsradmin (por ejemplo, Windows,
tasklist | findstr nsradmin)
3. Ejecute netstat para mostrar el conector asociado con ese proceso (por ejemplo, Windows,
netstat -ao | findstr process_id)
4. Determine el conector de conexión desde ese host (el emparejamiento de IP:puerto del extremo izquierdo en la salida)
5. En el host remoto, ejecute netstat -a y findstr/grep para :calling_port_from_first_host (ahora aparecerá en el lado derecho)
6. El nombre de host que aparece en el lado izquierdo de los dos puntos es el nombre del primer host con el que el segundo host resuelve la conexión entrante
7. Vuelva a ejecutar con el switch -n agregado al comando netstat para verificar la IP del mismo conector y comprobar si se espera la IP/ruta
8. Invierta la misma prueba para asegurarse de que el segundo host esté resolviendo el primer host dentro de los parámetros esperados