La implementación de IDPA falló con el error "Reverse lookup failed"

摘要: La implementación de IDPA falló con el error "Reverse lookup failed"

本文适用于 本文不适用于 本文并非针对某种特定的产品。 本文并非包含所有产品版本。
查看其他资源

症状



Nota: Versión de software afectada: 2.4 y versiones anteriores

Problema: La implementación inicial de IDPA falla en la fase de configuración de red del dispositivo con el siguiente error:

Error de flujo de trabajo: 
Configuring appliance network. [Step 1 of 4]Configuring Appliance Configuration Manager network. [Step 1 of 4]Appliance Configuration Manager network configuration completed. [Step 2 of 4]Network settings validation started. [Step 2 of 4]Network settings validation failed. Appliance network configuration failed. Error detallado: (Nota: x.x.x.11 corresponde a la IP pública de ACM y x.x.x.12 corresponde a la IP pública de ESXi) Reverse lookup failed for x.x.x.11 with primary domain name server x.x.x.240. Reverse lookup failed for x.x.x.12 with primary domain name server x.x.x.240. 


- Se aprobó la verificación de la herramienta NVT

- nslookup funciona correctamente para la búsqueda de DNS reversa e inversa

- Utilice la utilidad dnsjava de ACM para realizar la búsqueda de DNS que falló:
dpappliance-acm:~ # java -cp /usr/local/dataprotection/tomcat/webapps/dataprotection/WEB-INF/lib/vcedpa-externalutil-2.4.0.jar com.emc.vcedpa.network.IPResolveUtil x.x.x.240 x.x.x.11 Input : DNS[x.x.x.240], IP Address[x.x.x.11]. Hostname: x.x.x.11 Reverse lookup failed. Compare el resultado de nslookup de la misma consulta de DNS que se realizó correctamente: dpappliance-acm:~ # nslookup x.x.x.11 Server: x.x.x.240 Address: x.x.x.240#53 11.x.x.x.in-addr.arpa name = dp4400-acm.sample.local. 
Prueba n.º 1: en el resultado de tcpdump, se muestra una búsqueda de DNS fallida. El servidor x.x.x.240 no generó una respuesta a la consulta "ANY": =================================================================================== Desde ACM, capturamos el tráfico de red a partir de la consulta de DNS dnsjava que se presenta a continuación mediante la ejecución de los siguientes elementos: dpappliance-acm:~ # java -cp /usr/local/dataprotection/tomcat/webapps/dataprotection/WEB-INF/lib/vcedpa-externalutil-2.4.0.jar com.emc.vcedpa.network.IPResolveUtil x.x.x.240 x.x.x.11 Input : DNS[x.x.x.240], IP Address[x.x.x.11]. Hostname: x.x.x.11 Reverse lookup failed. dpappliance-acm:~ # nslookup x.x.x.11 Server: x.x.x.240 Address: x.x.x.240#53 11.x.x.x.in-addr.arpa name = dp4400-acm.sample.local. dpappliance-acm:~ # tcpdump -s 0 -i eth1 host x.x.x.240 -vvvv tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 01:18:07.955334 IP (tos 0x0, ttl 64, id 49262, offset 0, flags [DF], proto UDP (17), length 69) dp4400-acm.sample.local.48611 > x.x.x.240.domain: [bad udp cksum 0x2056 -> 0x2be5!] 33132+ PTR? 11.x.x.x.IN-ADDR.ARPA. (41) 01:18:07.955914 IP (tos 0x0, ttl 64, id 49263, offset 0, flags [DF], proto UDP (17), length 71) dp4400-acm.sample.local.33633 > x.x.x.240.domain: [bad udp cksum 0x2058 -> 0xa78f!] 39491+ PTR? 240.10.10.10.in-addr.arpa. (43) 01:18:07.956517 IP (tos 0x0, ttl 49, id 65199, offset 0, flags [none], proto UDP (17), length 139) x.x.x.240.domain > dp4400-acm.sample.local.48611: [udp sum ok] 33132* q: PTR? 11.x.x.x.IN-ADDR.ARPA. 1/1/1 11.x.x.x.IN-ADDR.ARPA. [1h] PTR dp4400-acm.sample.local. ns: 10.IN-ADDR.ARPA. [1h] NS ns.10.IN-ADDR.ARPA. ar: ns.10.IN-ADDR.ARPA. [1h] A 127.0.0.1 (111) 01:18:07.956815 IP (tos 0x0, ttl 49, id 46189, offset 0, flags [none], proto UDP (17), length 115) x.x.x.240.domain > dp4400-acm.sample.local.33633: [udp sum ok] 39491 NXDomain* q: PTR? 240.10.10.10.in-addr.arpa. 0/1/0 ns: 10.in-addr.arpa. [30m] SOA ns.10.in-addr.arpa. mail.10.in-addr.arpa. 102 28800 3600 604800 1800 (87) 01:18:07.956966 IP (tos 0x0, ttl 64, id 49264, offset 0, flags [DF], proto UDP (17), length 69) dp4400-acm.sample.local.57840 > x.x.x.240.domain: [bad udp cksum 0x2056 -> 0x71f6!] 30381+ PTR? 11.x.x.x.in-addr.arpa. (41) 01:18:07.957783 IP (tos 0x0, ttl 49, id 14608, offset 0, flags [none], proto UDP (17), length 139) x.x.x.240.domain > dp4400-acm.sample.local.57840: [udp sum ok] 30381* q: PTR? 11.x.x.x.in-addr.arpa. 1/1/1 11.x.x.x.in-addr.arpa. [1h] PTR dp4400-acm.sample.local. ns: 10.in-addr.arpa. [1h] NS ns.10.in-addr.arpa. ar: ns.10.in-addr.arpa. [1h] A 127.0.0.1 (111) 01:18:07.959536 IP (tos 0x0, ttl 64, id 49265, offset 0, flags [DF], proto UDP (17), length 69) dp4400-acm.sample.local.60791 > x.x.x.240.domain: [bad udp cksum 0x2056 -> 0x4144!] 61612+ ANY? dp4400-acm.sample.local. (41)01:18:08.960896 IP (tos 0x0, ttl 64, id 49284, offset 0, flags [DF], proto UDP (17), length 69)dp4400-acm.sample.local.47615 > x.x.x.240.domain: [bad udp cksum 0x2056 -> 0x74bc!] 61612+ ANY? dp4400-acm.sample.local. (41) 01:18:10.963164 IP (tos 0x0, ttl 64, id 49516, offset 0, flags [DF], proto UDP (17), length 69)dp4400-acm.sample.local.50636 > x.x.x.240.domain: [bad udp cksum 0x2056 -> 0x68ef!] 61612+ ANY? dp4400-acm.sample.local. (41) 01:18:14.967449 IP (tos 0x0, ttl 64, id 49830, offset 0, flags [DF], proto UDP (17), length 69)dp4400-acm.sample.local.44092 > x.x.x.240.domain: [bad udp cksum 0x2056 -> 0x827f!] 61612+ ANY? dp4400-acm.sample.local. (41) ^C 10 packets captured 10 packets received by filter 0 packets dropped by kernel Prueba n.º 2: en el resultado de tcpdump, se muestra que la búsqueda de DNS se realizó correctamente. Otro servidor DNS x.x.101 generó una respuesta a la consulta "ANY": ====================================================================================== Desde ACM, capturamos el tráfico de red para la ejecución del siguiente comando (x.x.x.101 es un socio de servidor DNS de prueba que se creó a sí mismo en una máquina virtual): dpappliance-acm:~ # java -cp /usr/local/dataprotection/tomcat/webapps/dataprotection/WEB-INF/lib/vcedpa-externalutil-2.4.0.jar com.emc.vcedpa.network.IPResolveUtil x.x.x.101 x.x.x.11 Input : DNS[x.x.x.101], IP Address[x.x.x.11]. Hostname: dp4400-acm.sample.local Reverse lookup successful.. Hostname: dp4400-acm.sample.local IP Address: x.x.x.11 Forward lookup successful. IP Address: x.x.x.11 dpappliance-acm:~ # tcpdump -s 0 -i eth1 host 10.15.1.101 -vvvv tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes 01:20:01.368557 IP (tos 0x0, ttl 64, id 4344, offset 0, flags [DF], proto UDP (17), length 69) dp4400-acm.sample.local.54907 > 10.15.1.101.domain: [bad udp cksum 0x16d0 -> 0xe01c!] 48674+ PTR? 11.x.x.x.IN-ADDR.ARPA. (41) 01:20:01.376214 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has dp4400-acm.sample.local tell 10.15.1.101, length 46 01:20:01.376222 ARP, Ethernet (len 6), IPv4 (len 4), Reply dp4400-acm.sample.local is-at 00:0c:29:93:b3:a0 (oui Unknown), length 28 01:20:01.376477 IP (tos 0x0, ttl 128, id 4475, offset 0, flags [none], proto UDP (17), length 106) 10.15.1.101.domain > dp4400-acm.sample.local.54907: [udp sum ok] 48674* q: PTR? 11.x.x.x.IN-ADDR.ARPA. 1/0/0 11.x.x.x.IN-ADDR.ARPA. [1h] PTR dp4400-acm.sample.local. (78) 01:20:01.378905 IP (tos 0x0, ttl 64, id 4346, offset 0, flags [DF], proto UDP (17), length 69) dp4400-acm.sample.local.55796 > 10.15.1.101.domain: [bad udp cksum 0x16d0 -> 0x948b!] 47726+ ANY? dp4400-acm.sample.local. (41) 01:20:01.379318 IP (tos 0x0, ttl 128, id 4476, offset 0, flags [DF], proto UDP (17), length 85) 10.15.1.101.domain > dp4400-acm.sample.local.55796: [udp sum ok] 47726* q: ANY? dp4400-acm.sample.local. 1/0/0 dp4400-acm.sample.local. [1h] A 10.15.1.11 (57) 01:20:06.393279 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.15.1.101 tell dp4400-acm.sample.local, length 28 01:20:06.394227 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.15.1.101 is-at 00:0c:29:6f:47:b6 (oui Unknown), length 46

原因

Con el módulo de cliente DNS IDPA ACM actual: dnsjava (v2.4 o anterior), se enviaría una consulta de tipo "ANY" al servidor DNS para la búsqueda inversa. La mayoría de los servidores DNS pueden responder correctamente a las consultas de tipo "ANY", pero para los servidores DNS que no pueden procesar una consulta "ANY", la búsqueda inversa falla 

解决方案

El problema se solucionará después de la v2.4

Si IDPA se ejecuta en las versiones v2.4 o anteriores, existen dos soluciones alternativas: 
1: Pruebe con un servidor DNS diferente que sea compatible con el tipo "ANY" de consulta de DNS
2: Cree un ticket de asistencia técnica para obtener ayuda.

受影响的产品

Integrated Data Protection Appliance Family

产品

Integrated Data Protection Appliance Family
文章属性
文章编号: 000060380
文章类型: Solution
上次修改时间: 18 4月 2026
版本:  4
从其他戴尔用户那里查找问题的答案
支持服务
检查您的设备是否在支持服务涵盖的范围内。