¿El enrutador utiliza NAT?


2

Sé que las computadoras en diferentes subredes no pueden comunicarse a menos que usemos un enrutador.

Por ejemplo:

  • PC A está en subred 192.168.1.0/24 y B está en 192.168.2.0/24.

  • A y B están conectados con enrutador C con interfaces 192.168.1.1 , 192.168.2.1 .

Cuando se envía un paquete de A a B, ¿el enrutador envía el paquete usando NAT (traducción de direcciones de red) ?

Si no es así, ¿cómo podrían A y B comunicarse entre sí?

Soy un novato en redes.


3
Si todos esos son sus dispositivos y no hay ningún tipo de conexión a Internet, no habría NAT. NAT es el proceso de comunicación con un conjunto limitado de IP y enmascaramiento de los demás que tienes. El ejemplo más común es su acceso a internet en casa. Está utilizando IP privadas para su PC, TV y teléfono y solo una única IP pública para acceder a Internet. La simple comunicación entre subredes sería un enrutamiento simple. Consulte algunas de las otras preguntas de la red o el artículo de Wikipedia sobre NAT y enrutamiento para obtener más información. Bienvenido a SU.
Seth

1
Leer sobre enrutamiento (Es por eso que estos dispositivos se llaman "routers"). Si C es la puerta de enlace predeterminada para A y B, solo necesita configurar las rutas en C. La mayoría de los enrutadores son cajas Linux integradas, por lo que ip route add ... en la cuenta de root, o cualquier archivo de configuración que use.
dirkt

Respuestas:


3

Cuando se envía un paquete de A a B, ¿el enrutador envía el paquete utilizando NAT (traducción de dirección de red)?

Por lo general no. Eso técnicamente podría, pero no tiene que hacerlo, no hay necesidad de NAT en esta situación.

(Supongo que C actúa como "puerta de enlace predeterminada" tanto de A como de B).

Si no es así, ¿cómo podrían A y B comunicarse entre sí?

Intenta la pregunta opuesta: por qué es ¿NAT necesaria para algunos tipos de comunicación?

NAT se vuelve necesario porque Internet no sabe dónde están las direcciones "internas"; sólo sabe dónde está tu dirección "pública". Por lo tanto, la única forma de obtener respuestas de los hosts de Internet es simular que se enviaron desde la dirección pública del enrutador.

Pero en su ejemplo, el enrutador sabe perfectamente dónde están ambas subredes. Y si el enrutador es la puerta de enlace predeterminada de ambos hosts, eso significa que los hosts también saben lo suficientemente bien como llegar a la subred opuesta: A tiene una ruta a B, B tiene una ruta a A, C tiene rutas a ambos. Por lo tanto, la razón mencionada anteriormente para NAT no se aplica.


¿El paquete IP después del enrutador mantiene el original?
Andrew Li

Sí. (¿Por qué no?)
grawity

2

Según la información proporcionada en la pregunta, no es posible saber si el enrutador está funcionando NAT o no. Sin embargo, se puede usar una prueba simple para determinar si NAT está en uso:

Si puede hacer ping a la PC B con éxito desde la PC A y viceversa usando la dirección IP real de cada PC, entonces el enrutador es no realizando NAT. (Esto supone que no hay servidores de seguridad que bloqueen el ping, por lo que es posible que deba deshabilitar cualquiera, incluso en las PC).

Por el contrario, si NAT está en uso, la PC "está detrás" de NAT será ser capaz de hacer ping a la otra computadora, pero no funcionará al revés. Por ejemplo, la PC A está detrás de un enrutador que realiza NAT, podría hacer ping a B, pero B no podría hacer ping a A (usando la dirección IP real de A). Esto se debe a que NAT traduce (es decir, enmascara) la dirección IP de la PC A para que parezca que tiene una dirección IP en la misma subred que la PC B. Esto es útil cuando tiene muchos dispositivos en la subred A, cada uno con su propia Dirección IP, pero solo tiene una dirección IP en la subred B (que podría ser Internet). NAT permite que todos esos dispositivos se comuniquen con el resto de la red / Internet a través de una sola dirección IP. Esto se usa ampliamente para mitigar el impacto de Agotamiento de IPv4 .

Si NAT no está en uso, entonces el enrutador simplemente hace lo que todos enrutadores do ... envía paquetes desde la PC A con destino a la PC B desde la interfaz correcta para que lleguen a su destino. La mayoría de los enrutadores tienen múltiples interfaces conectadas a una variedad de redes, como puede ser el caso en una organización donde varios edificios tienen su propia red conectada por un enrutador central.

La mayoría de los "enrutadores" que conectan dos redes, específicamente una LAN a Internet, no son enrutadores reales en sentido estricto, sino que son Puertas residenciales .


Ambas PC deben tener una puerta de enlace (puerta de enlace predeterminada o ruta común) a la subred de otra PC a través de la dirección del enrutador en su subred. De lo contrario, causará ping unidireccional o ninguno mientras NAT y ninguno ping sin que dependa de qué PC tenga o no tenga la configuración de puerta de enlace adecuada. Se puede obtener información adicional al buscar el error de ping (tiempo de espera o destino inalcanzable).
Akina

@Akina tienes razón. Supongo que en la red de ejemplo del OP, el enrutador conectado a cada subred funciona como la puerta de enlace predeterminada de esa red.
Twisty Impersonator

192.168.1.3 y 192.168.2.4 podrían comunicarse entre sí en la misma LAN?
Andrew Li

1
@AndrewLi Directamente, sin enrutador? Solo cuando su máscara de subred es / 22 o más ancha, de lo contrario no.
Akina

1
"Si puede hacer ping a la PC B con éxito desde la PC A y viceversa usando la dirección IP real de cada PC, entonces el enrutador no está realizando NAT", no, esto no es necesariamente cierto. Mientras que SNAT traduce los paquetes salientes, no bloquea mágicamente los entrantes. Siempre y cuando el cortafuegos lo permite (y mientras existan las rutas), es perfectamente posible hacer ping / llegar a una subred que sería NATed saliente. Lo que hay que comprobar es si los paquetes Recibido por La PC B todavía tiene la dirección IP de origen de la PC A, en lugar de la del enrutador.
grawity
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.