Conexi贸n de dispositivos en rango de IP privado – UNMS

Introducci贸n


En ocasiones, es posible que se sienta obligado a volver a escribir el FQDN en su clave UNMS gen茅rica con una direcci贸n IP para poder conectar un dispositivo dentro de su red a UNMS. En esta situaci贸n, a menudo es 煤til verificar si hay un NAT de origen correcto configurado en su puerta de enlace. En este art铆culo, explicaremos qu茅 est谩 sucediendo y c贸mo solucionar la situaci贸n. 


Diagrama de Red

Screen_Shot_2018-04-25_at_10.12.01_AM.png

Configurando el NAT


En el esquema anterior, el dominio myunms.comest谩 configurado en 99.98.97.96 y hay una redirecci贸n en la puerta de enlace de 99.98.97.96:443 a 192.168.1.20:443. Si la direcci贸n myunms.comse abre desde el dispositivo airMAX, no funcionar谩. 

La raz贸n de ello es que el dispositivo airMAX pidi贸 a DNS que tradujeramyunms.comy recibi贸 la direcci贸n p煤blica 99.98.97.96. Cuando el primer paquete se env铆a all铆, el enrutador de la puerta de enlace (EdgeRouter 4 en este ejemplo) intercepta el paquete y reescribe la IP de destino a 192.168.1.20 (servidor UNMS). El servidor UNMS recibe el paquete y responde con el paquete ACK (reconoce la conexi贸n) que viaja a una direcci贸n del remitente: 129.168.1.21 (dispositivo airMAX). Pero el dispositivo airMAX envi贸 una solicitud al servidor 99.98.97.96 y ese servidor nunca respondi贸, por lo que la conexi贸n finalmente termina. En su lugar, el dispositivo airMAX recibe un paquete ACK de 192.168.1.20, que el dispositivo airMAX nunca intent贸 contactar para que el paquete se descarte. 

La soluci贸n a este problema es agregar una regla a la puerta de enlace que ser谩 la Fuente NAT y todos los paquetes ir谩n a 192.168.1.20. Aqu铆 hay una gu铆a sobre c贸mo configurar la fuente NAT en los dispositivos EdgeRouter . Esta t茅cnica se suele denominar NAT Reflection / NAT Loopback / NAT Hairpinning.