Respuestas NAT y UDP

20

Control de cordura por favor.

Si envío paquetes UDP desde la máquina A detrás de un NAT al puerto N de la máquina B, donde la máquina B está fuera del NAT (en otra parte de Internet), ¿puedo esperar razonablemente que NAT pase los paquetes UDP recibidos desde la máquina B en el puerto N de nuevo a puerto N en la máquina A, sin necesidad de reenvío manual de puertos en el NAT?

tomfanning
fuente

Respuestas:

21

Solo si el puerto de origen del datagrama saliente original también era el puerto N, y si el NAT no eligió flotar el puerto de origen.

Es decir, el primer datagrama UDP de la máquina A se ve así en su LAN:

       Source IP: MachineAPrivate  
     Source Port: PortA     <-- note this is typically different than the destination port  
  Destination IP: MachineBPublic  
Destination Port: PortN  

Luego, después de que el NAT lo traduzca en la dirección de salida, se ve así:

       Source IP: NATPublic  
     Source Port: PortC   <-- note this may or may not be the same as "PortA" above  
  Destination IP: MachineBPublic  
Destination Port: PortN  

Ahora, cuando la máquina B responde, la respuesta generalmente se ve así:

       Source IP: MachineBPublic  
     Source Port: PortN  
  Destination IP: NATPublic  
Destination Port: PortC  

Luego, después de pasar por el proceso de traducción NAT entrante:

       Source IP: MachineBPublic  
     Source Port: PortN  
  Destination IP: MachineAPrivate  
Destination Port: PortA  

Entonces, SI la máquina A envía la trama desde el mismo puerto de origen que el puerto de destino ("Puerto N"), y SI el NAT puede preservar ese puerto de origen (es decir, está configurado para preservar los puertos de origen cuando sea posible, y ese puerto de origen no está en uso), ENTONCES puede esperar una respuesta al "Puerto N" para volver a la Máquina A.

Aquí está la referencia autorizada sobre el comportamiento apropiado de UDP NAT:
RFC 4787 / BCP 127: Requisitos de comportamiento de traducción de direcciones de red (NAT) para UDP unidifusión

Spiff
fuente
3

Cerrar, pero la Máquina B necesita mirar la dirección de origen y el número de puerto que realmente recibe, que puede ser diferente de N.

Es posible que el NAT en la máquina A no use el mismo puerto N que envió la máquina A. (Imagine que la máquina C detrás de ese mismo NAT también envía en el puerto N: ambos no pueden usarlo). Entonces, la máquina B podría ver un puerto de origen diferente, M. Pero si el NAT hace eso, entonces debería aceptar el tráfico enviado de regreso a puerto M y automáticamente asignarlo de nuevo a N en la máquina B.

En otras palabras, siempre y cuando la Máquina B envíe de vuelta a la dirección de origen y al puerto de origen que figuran en el paquete que recibió, puede esperar razonablemente que el paquete de retorno regrese a la fuente original. Esto supone que el paquete de devolución se envía en un corto período de tiempo, ya que las reglas NAT automáticas tienden a agotar el tiempo después de algunos minutos.

Seth Noble
fuente
-1

No esperaría eso.

Puede multiplicar las IP detrás de NAT, por lo que debe elegir a qué reenvío. Fuera de NAT, solo la IP del enrutador está visible y las IP de NAT internas no están visibles.

UDP no forma una conexión, pero es solo un datagrama que viaja a través de la red.

También hay una diferencia entre enviar el puerto y recibir el número de puerto.

rumburak
fuente
Tiene razón en que UDP no "forma una conexión", sin embargo, los puertos de origen y destino emparejados en realidad permiten que el NAT identifique de forma exclusiva a qué IP detrás del NAT enviar los paquetes
portforwardpodcast