Problema de NAT de iptables con conexiones que involucran paquetes RST

Problema de NAT de iptables con conexiones que involucran paquetes RST

Tengo una configuración que se parece a la siguiente.

Aplicación > Servidor local > VPN > Servidor VPN remoto > Servidor de licencias

La aplicación y el servidor local están en mi LAN. El servidor local se conecta a través de una VPN al servidor VPN corporativo, que es la forma en que el servidor local puede ver el servidor de licencias corporativo.

Le digo a mi aplicación que busque una licencia en mi servidor local y agregue las siguientes reglas de iptables a mi servidor local.

iptables -F
iptables -t nat -F
iptables -X

licServer=$(host licserver | awk '/has address/ { print $4 ; exit }')
iptables -t nat -A PREROUTING -p tcp --dport 1642 -j DNAT --to-destination $licServer:1642
iptables -t nat -A PREROUTING -p tcp --dport 57109 -j DNAT --to-destination $licServer:57109

iptables -t nat -A POSTROUTING -j MASQUERADE

Esto parece funcionar y la aplicación adquirirá una licencia con éxito. Sin embargo, la negociación es muy lenta en comparación con una sesión local (que no usa mis reglas).

Si miro Wirehark, veo que la aplicación envía algunos mensajes inusuales. Nunca se envían paquetes FIN, sino que la aplicación envía paquetes RST. Noto que cada vez que envía uno de estos paquetes RST, hay una espera casi exacta de 10 segundos antes de enviar el siguiente mensaje. No creo que esto sea una coincidencia, ya que el tiempo de espera de CLOSE_WAIT es de 10 segundos.

Una negociación típica comenzaría algo como lo siguiente

t=0 Application:A > Local Server:1642 [SYN]
t+0.1 Local Server:1642 > Application:A [SYN, ACK]
t+0.1 Application:A > Local Server:1642 [ACK]
t+0.1 Application:A > Local Server:1642 [PSH, ACK]
t+0.2 Local Server:1642 > Application:A [PSH, ACK]
t+0.2 Application:A > Local Server:1642 [RST, ACK]   (10 second wait here)
t+10.2 Application:B > Local Server:57109 [SYN]

... etcétera. Siempre que hay un RST, espera otros 10 segundos.

Cuando la aplicación es local para el servidor de licencias, se envían los mismos mensajes, pero no hay una espera de 10 segundos después de enviar el paquete [RST, ACK].

Por lo tanto, mi pregunta es: ¿qué hace NAT en mi servidor que podría provocar que mi aplicación se cuelgue durante 10 segundos después de enviar un paquete RST?

Respuesta1

No importa, resulta que el problema no tenía ninguna relación con NAT.

El servidor de licencias enviaba su propio nombre de host como parte de la carga útil de un paquete anterior. Obviamente, la aplicación no pudo contactar con este nombre de host, por lo que los 10 segundos provienen de un tiempo de espera en la aplicación. Supongo que intenta con el nombre de host, luego, después de 10 segundos, prueba con la primera dirección que tenía (así es como funciona finalmente).

Una vez que agregué el nombre de host del servidor de licencias al archivo de hosts en la máquina cliente, funciona.

Me siento como un idiota real. Gracias a todos los que miraron.

información relacionada