Intentando comprender las interacciones entre dos subredes diferentes en la misma red


9

Tengo una 10.0.0.0/8red dividida en dos partes. Un servidor DHCP reparte direcciones 10.0.0.10a 10.0.0.150con una máscara de clase A ( 255.0.0.0). Esta es mi parte de "Invitado" de la red.

Usuarios de la red autorizados tienen reservas sobre el servidor DHCP con direcciones en el 10.100.0.10de 10.100.0.250gama con una máscara de clase A.
Un servidor de archivos en la red tiene una dirección IP 10.100.0.1y una máscara de clase B ( 255.255.0.0).

  • Los dispositivos tanto en la red "Invitada" como en la red "Autorizada" pueden verse entre sí.
  • La red "Autorizada" puede ver el servidor de archivos.
  • La red "Invitado" no puede ver el servidor de archivos.

Esto ha funcionado bastante bien hasta ahora, pero mi instructor de clase jura que no debería. He leído en varios lugares que las PC con máscaras de subred asignadas no deberían poder comunicarse entre sí.

¿Puede alguien ayudarme a entender por qué las PC de red "autorizadas" pueden acceder al servidor de archivos sin problemas a pesar de las diferentes máscaras de subred?


1
Gracias por la edición, JakeGould. Eso se ve mucho mejor
Jared

Respuestas:


13

La teoría de la máscara de subred es que define qué parte de la dirección IP es la dirección de red y qué parte de la dirección IP es la dirección de host:

10.100.0.1 - Dirección IP;

255.0.0.0 - Máscara de subred;

10- dirección de red, 100.0.1- dirección de host.

Los hosts dentro de la misma subred pueden comunicarse directamente entre sí. Eso significa que si el host A y B se encuentran dentro de la misma subred y A quiere hablar con B, entonces A enviará su tráfico directamente a B. Si el host A quiere hablar con el host C que se encuentra en una subred diferente, entonces A tendrá para enrutar este tráfico a la puerta de enlace que sabe (con suerte) cómo llegar a diferentes redes. Por lo tanto, depende del host definir dónde enviar el tráfico:

  1. Directamente al host (el segundo host está dentro de la misma subred)
  2. A la puerta de enlace (el segundo host pertenece a una subred diferente)

Lo que sucede en su caso es que sus clientes "autorizados" tienen direcciones IP 10.100.0.10 - 10.100.0.250(supongo que la máscara de subred es 255.0.0.0). El servidor tiene dirección IP 10.100.0.1. Para un host del rango "Autorizado", este servidor se encuentra en la misma subred.

Si el host 10.100.0.10del rango "Autorizado" quiere hablar con el servidor, primero verifica si este servidor está ubicado en la misma subred o no. Para el host 10.100.0.10con máscara de subred, la 255.0.0.0misma subred sería todos los hosts dentro del rango 10.0.0.1 - 10.255.255.254. La dirección IP del servidor está en este rango. Por esta razón, un host del rango "Autorizado" intenta alcanzar el servidor directamente y (suponiendo que se encuentren en la misma red de Capa 2) este intento tiene éxito.

En este caso, aunque el servidor tiene una máscara de subred diferente, está ubicada en la subred más grande (que también es una subred para los clientes "autorizados"). Si su servidor tendrá un segundo byte diferente en la dirección IP ( 10.150.0.1por ejemplo), no podrá responder al host desde el rango "Autorizado", porque desde la perspectiva del servidor, el rango "Autorizado" se vería como una subred y servidor diferentes necesitaría enviar tráfico a un enrutador. Si no hubiera enrutador, entonces no habría comunicación.

Si desea separar su red de las partes "Invitados" y "Autorizadas", debe hacer que se ubiquen en las diferentes subredes que no se superponen.

Por ejemplo:

  1. "Invitados" - 10.10.0.1, máscara de subred255.255.0.0
  2. "Autorizado" - 10.20.0.1, máscara de subred255.255.0.0

El servidor se ubicaría dentro de la parte "Autorizada" de la red con dirección IP 10.20.0.100, máscara de subred 255.255.0.0.

Con esta configuración, estas subredes se separarán efectivamente entre sí, ya que las partes de las direcciones IP que representan su subred serán diferentes:

  1. 10.10 para invitados
  2. 10.20 para autorizado

En este punto, la comunicación entre estas subredes será posible solo a través de un enrutador que tenga interfaces en ambas subredes.

Además, vale la pena mencionar que, si bien todas sus computadoras comparten la misma red de Capa 2, nada impedirá que los Invitados se asignen manualmente direcciones IP del rango "Autorizado". Esto hará que formen parte de la red autorizada.


5

Todas las máquinas "autorizadas" e "invitadas" están en la misma subred, por lo que no es de extrañar que todas puedan comunicarse entre sí.

La máscara de subred restringida del servidor hace pensar que solo las computadoras "autorizadas" se encuentran en la misma subred, por lo que los ARP se dirigen directamente a ellas y pueden acceder a ellas.

El servidor cree que las computadoras "Invitadas" están en una subred diferente, por lo que intenta enviar sus paquetes a su puerta de enlace predeterminada (es decir, en la capa de Ethernet, las dirige a la dirección MAC de la puerta de enlace predeterminada; todavía están dirigidas a las computadoras "Invitadas" en la capa IP). Si el servidor no tiene una puerta de enlace predeterminada definida, o si su puerta de enlace predeterminada es inalcanzable o está mal configurada, estos paquetes no podrán llegar a las computadoras "Invitadas".


3

Dado que los paquetes están fuera de su rango de LAN, envían los paquetes a su enrutador predeterminado. Su enrutador predeterminado los reenvía a su destino y envía una redirección ICMP a la fuente. Independientemente de si la redirección ICMP funciona o no, el tráfico sigue llegando.

Definitivamente no debes hacer las cosas de esta manera.


Si entiendo su respuesta, un ping de la red Guest llegará al servidor de archivos, pero la respuesta del servidor de archivos irá a la puerta de enlace predeterminada en lugar de responder directamente al host Guest. ¿El enrutador no sabrá a dónde enviar el tráfico y lo descargará por un agujero? No quiero que el servidor de archivos hable con los hosts de la red Guest, por lo que parece una ventaja. ¿Por qué es una mala idea?
Jared

1
@jared Lea esta oración: "Su enrutador predeterminado los reenvía a su destino y envía una redirección ICMP a la fuente". Esto significa que todo lo que hace su configuración actual es agregar un "salto" adicional al tráfico. El paquete se "pierde" va al enrutador pidiendo ayuda y luego se redirige de todos modos. Así que nada se tira por el agujero. Simplemente se desvía.
JakeGould
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.