Para usuarios de TCP y UDP NAT información del puerto. Para otros protocolos como ICMP, puede usar trucos específicos del protocolo. ¿Qué sucede si se usa un protocolo IP que no se atiende o no se reconoce?
¿Puede un paquete así salir de la interfaz de destino? Si es así, ¿qué pasa? ¿Se acaba de cambiar la IP de origen? ¿Qué pasa en el camino de regreso? ¿Es posible que un paquete de retorno pueda ir a la dirección IP incorrecta? ¿Quizás incluso todos los ips disponibles?
Respuestas:
Para usuarios de TCP y UDP NAT información del puerto. Para otros protocolos como ICMP, puede usar trucos específicos del protocolo.
Bueno, los mismos TCP y UDP también son "trucos específicos del protocolo": en realidad no son diferentes de los "ID de solicitud" de ICMP Echo o los "SPI" de IPsec. (NAT en sí es un 'truco').
¿Puede un paquete así salir de la interfaz de destino? Si es así, ¿qué pasa? ¿Se acaba de cambiar la IP de origen?
Por lo general, si. La mayoría de los NAT pasarán a través de dichos paquetes incluso si no reconocen el protocolo interno, ya que aún tiene una mayor probabilidad de funcionar que "descartar todo".
¿Qué pasa en el camino de regreso?
Depende de si el NAT realmente realizó un seguimiento del paquete saliente. (Varía.)
Incluso si el NAT no comprende cómo extraer puertos o ID fuera del protocolo interno, aún puede realizar un seguimiento del tipo de protocolo , que podría ser suficiente para algunas situaciones. (Cada paquete de IP tiene un campo de tipo de protocolo, por lo que lo que llama "IP sin procesar" es simplemente un caso de "tipo de protocolo de IP desconocido").
Por ejemplo, una conexión TCP (protocolo IP 6) y un ping ICMP (protocolo IP 1, ICMP tipo 8) se rastrearían como:
host 192.168.1.2 (as 42.0.2.1) → 62.205.132.12` proto 6`port 21445 → 80host 192.168.1.2 (as 42.0.2.1) → 62.205.132.12` proto 1`type 8 code 0 id 1227Mientras tanto, un protocolo no reconocido como un túnel 6in4 se rastrearía como:
host 192.168.1.2 (as 42.0.2.1) → 62.205.132.12` proto 41`—Por lo tanto, todos los protocolos-41 paquetes entrantes se enviarían de vuelta a 192.168.1.2. Esto significa que una computadora aún podría hablar el protocolo, pero dos computadoras a la vez probablemente no. (Al igual que con UDP, algunos NAT también verifican la dirección IP de origen, pero muchos solo se preocupan por el protocolo y el puerto).
Si bien he utilizado 6en4 en el ejemplo anterior, la misma también sucedería con todos los protocolos que la NAT no entiende, aunque lo tienen puertos (por ejemplo, UDP-Lite o SCTP).
conntrack -Lo cat /proc/net/nf_conntrackver todos los estados que se están rastreando actualmente. Algunos enrutadores incluso muestran esto en su interfaz de usuario web.Finalmente, si el NAT no mantuvo ningún estado, entonces se supone que el paquete está destinado al enrutador (igual que con cualquier otro paquete entrante no rastreado), y generalmente se cae al suelo.
¿Es posible que un paquete de retorno pueda ir a la dirección IP incorrecta?
En el caso más simple, no. O el NAT puede asociar el paquete de retorno con algún estado conocido, o no puede, pero no generará basura al azar. (Generalmente.)
Sin embargo, si dos computadoras detrás de la LAN están tratando de hablar el mismo protocolo al mismo host remoto, entonces sus estados pueden entrar en conflicto. El que gana puede variar: o el estado más antiguo se usa hasta que caduca (por lo que las respuestas para ambas computadoras continúan yendo al primero), o se anulan mutuamente cada cierto tiempo (es decir, cambia de lugar entre ambos). Es una situación en la que NAT dinámica definitivamente no fue diseñada para ...
¿Quizás incluso todos los ips disponibles?
No. Es posible en teoría, por ejemplo, algunas personas hacen esto con configuraciones de reenvío de puertos estáticos para Wake-on-LAN, pero hacerlo de forma predeterminada no sería muy útil. En todo caso, haría que su LAN sea más vulnerable a los paquetes falsificados.
(Aunque, de hecho, así es como funciona la conmutación de Ethernet: los paquetes para MAC desconocidos se inundan a través de todos los puertos físicos).
Como nota al margen, esto no es realmente específico para los NAT IPv4. El seguimiento de estado es una parte integral de un firewall con estado , utilizado tanto por IPv4 como por IPv6. Incluso sin NAT / PAT, el seguimiento de estado también permite que el firewall acepte automáticamente todos los paquetes conocidos y rechace los desconocidos.
Entonces, cuando las personas afirman que "NAT agrega seguridad", en realidad están hablando de la configuración del firewall que generalmente viene con él (y se puede usar igualmente bien sin NAT).
net/netfilter/nf_conntrack*.c(donde se implementa el seguimiento de estado) y la conntrackherramienta (para examinar exactamente qué estados se conocen en este momento).
NAT es un tema interesante.
Hay tres tipos de NAT:
PAT es lo que usan la mayoría de los enrutadores de consumo, así que vamos por ese.
Imaginemos que tengo este diseño en casa:
Router 192.168.0.1
PC 1 192.168.0.2
PC 2 192.168.0.3
External IP 1.1.1.1 (Lets assume I have that one)
Mis dos computadoras quieren conectarse a www.superuser.com que tiene la ip 151.101.65.69.
Cargo mi navegador en PC1 y escribo www.superuser.com y sucede lo siguiente:
Al mismo tiempo, la PC 2 podría pasar al mismo proceso, pero lo más probable es que elija un puerto separado. El enrutador toma nota de estos números de puerto y baraja el tráfico según sea necesario al destino correcto.
El enrutador mantendrá una tabla como esta:
Source Destination
192.168.0.2:40000 151.101.65.69:80
192.168.0.3:56944 151.101.65:69:80
Ahora pregunta: "Pero Lister, ¿qué sucede si el número de puerto aleatorio que has elegido ya está en uso? ¡Has roto el sistema Lister!" Eso está completamente bien, el enrutador incrementará el número de puerto en su lista al siguiente disponible, pero recordará enviar la información del puerto correcto a la PC.