Tengo curiosidad por recibir algunos comentarios sobre cómo otros hacen esto.
Un sitio que estoy viendo tiene varios edificios conectados por fibra y cada uno está en su propia subred.
192.168.0.0 - Building 1 - VLAN10
192.168.1.0 - Building 2 - VLAN20
192.168.2.0 - Building 3 - VLAN30
etc.
(para que conste, entiendo las implicaciones no deseadas de estar en una subred 192.168)
Cada edificio ejecuta su propio pequeño centro de datos con servidores DHCP y controladores de dominio.
Mi gran problema es que creo que es muy confuso tener servidores en
192.168.0.1 - building 1
192.168.0.5 - building 1
192.168.1.11 - building 2
192.168.2.5 - building 3
etc.
Obviamente, podría decir que coloque todos los equipos de red en la subred 192.168.0.0 y todos los servidores en 192.168.1.0, DHCP en 192.168.3.0, pero esto crearía VLAN cruzadas.
Por ejemplo, probablemente todavía querría un servidor DHCP en VLAN20 con todas las computadoras en ese edificio, y también un servidor DHCP en VLAN10 con esas computadoras en ese edificio.
Por tradición, las VLAN se mantienen 1 a 1 con su subred.
¿Cómo logran otros esto? ¿Sabe que 192.168.0.1-.50 está reservado para equipos de servidor?
Vengo de una red 10.1.0.0/21, por lo que teníamos suficientes direcciones para mantener todo separado y no lo hicimos en absoluto.
Respuesta1
Esta es una pregunta muy difícil de responder basándose en un escenario porque hay muchos factores a considerar con poca información proporcionada. Sin embargo, en un sentido general, esta es mi idea.
En primer lugar, estoy de acuerdo con los comentarios en contra de la pregunta de que ningún grupo de direcciones privadas es más o menos deseable que otro en función de su susceptibilidad a ser similar a los usuarios domésticos. Según mi experiencia, no importa cuánto intente evitar conflictos con los usuarios de VPN, si no le ocurre al usuario 'A', eventualmente habrá algún usuario 'B' al que sí le sucederá.
Una cosa fundamental que no mencionó en la pregunta es el volumen de dispositivos y el crecimiento esperado durante la vida útil de la infraestructura. Mantendré los puntos generales, debido al alcance abierto y la ambigüedad.
Si está decidido a dividir su red en subredes por edificio, primero identifique la cantidad de edificios que se necesitan y luego considere la probabilidad de que esto sea suficiente a largo plazo (5 a 10 años). Intenta llegar a una cantidad de redes que no sea excesiva pero sí realista. Normalmente sería liberal y permitiría gastos generales marginales. Utilice esto para definir el rango más estrecho práctico para subredes de nivel superior.
Por ejemplo, si tiene 3 edificios, pero prevé que podrían crecer a 5 en 10 años, elija un múltiplo de base dos que sea sensato para esto y divida el primer octeto utilizable con este prefijo. P.ej. de 172.16.xx con hasta 8 redes:
000 | x xxxx . xxxx xxxx - Common Equiptment. 192.168.0.0 /19
001 | x xxxx . xxxx xxxx - Building 1. 172.16.32.0 /19
010 | x xxxx . xxxx xxxx - Building 2. 172.16.64.0 /19
011 | x xxxx . xxxx xxxx - Building 3. 172.16.96.0 /19
100 | x xxxx . xxxx xxxx - Building 4. 172.16.128.0 /19
Esto maximizará el alcance de su dirección y permitirá realizar más subredes. También simplifica la definición de rutas si todas las subredes dentro de cualquier alcance .19 pasan por el mismo nodo para la mayor parte de la red restante. Tenga en cuenta que este equilibrio debería funcionar de dos maneras. Digamos, por ejemplo, que tiene una pequeña cantidad de edificios además de sus edificios principales, como oficinas remotas, que no necesitan muchas direcciones, sino que simplemente necesitan estar conectadas; podría asignarles una subred 'principal' de un solo edificio. y dividirlo para atenderlos. En última instancia, su objetivo es mantener el mayor espacio de direcciones donde probablemente sea más necesario.
Desde aquí, es posible que descubra que divide aún más su red en asignaciones específicas de la aplicación. Podrías hacer algo como lo siguiente:
Edificio 1 (desde arriba).
001 | 0 0 | xxx . xxxx xxxx - Building 1's Default Network. 172.16.32.0 /21
001 | 0 1 | xxx . xxxx xxxx - Building 1's Misc Networks. 172.16.40.0 /21
001 | 1 0 | xxx . xxxx xxxx - Building 1's Phone Network. 172.16.48.0 /21
Podríamos llevar esto más lejos y tener:
001 | 0 1 | xxx . xxxx xxxx - Building 1's Misc Networks. 172.16.40.0 /21
001 | 0 1 | 001 . xxxx xxxx - Management Network. 172.16.41.0 /24
001 | 0 1 | 010 . xxxx xxxx - Security Camera Network. 172.16.42.0 /24
001 | 0 1 | 011 . xxxx xxxx - Alarm System Network. 172.16.43.0 /24
Siento que lo importante es encontrar una solución que funcione para su situación. Probablemente querrás:
- Maximizar el espacio para el crecimiento, donde es más probable que ocurra. Supongo que sería su red de usuarios finales.
- Mantenga patrones consistentes siempre que sea posible, para que las ACL y las reglas de firewall puedan simplificarse. Por ejemplo, si sabe en el 3.º octeto que los bits 4.º y 5.º con el patrón '01' siempre denotarán las 'redes varias', podría tener una máscara de bits para capturar todos los edificios en una sola regla.
- En lugar de centrarse en si un espacio de direcciones podría entrar en conflicto con la red doméstica de un usuario, intente centrar su diseño en cómo lo utilizarán. Por ejemplo; Si se trata de una VPN punto a punto, sin traducción ni sobrecarga, con tráfico enrutado adicional que pasa, puede ser importante mantener alcances de direcciones compatibles. Sin embargo, para la mayoría de los usuarios domésticos, la colisión no importará, porque se conectarán desde su dispositivo final y su dispositivo tratará su conexión como puerta de enlace para todo el tráfico. Cualquier desviación de esto podría ir en contra de su política de uso y estar fuera del alcance de su soporte.
- Las redes de la misma subred no necesitan estar en la misma VLAN... pero probablemente deberían estarlo. La ID de VLAN es exactamente eso; solo un numero. No es necesario que sea el mismo en todos los dispositivos conectados si no lo intercambian, pero no se me ocurre ningún escenario en el que sería beneficioso tener una estructura de ID de VLAN inconsistente. Para unir dos VLAN diferentes de la misma red, usaría un puente (conmutador). Básicamente, habrá dividido un conmutador en múltiples subconmutadores y los habrá unido de manera ineficiente de una manera que es difícil de mantener.
- Minimiza el enrutamiento innecesario. Si bien tener todas estas redes puede ser agradable y lógico, si un gran volumen de tráfico pasa de la red A a la red B a través de un enrutador, no es suficiente simplemente asumir que el enrutador es capaz de soportarlo bajo la premisa de que su puerto acelera. son adecuados. Por ejemplo, el enrutador Cisco 1941 de doble gigabit Ethernet, aunque tiene dos puertos gigabit, solo tiene un rendimiento especulado de 153 Mbps entre redes. (Especificaciones de rendimiento)
- No tenemos suficientes redes (...con ánimo de ser contradictorios). Si no usara subredes para dividir su red, una transmisión llegaría a todos los dispositivos. Si descubre que ciertos grupos de dispositivos no necesitan comunicarse directamente con frecuencia, es una buena indicación de que deben separarse.
- Adopte la escalabilidad horizontal, tanto dentro como entre redes. En lugar de tener un gran servidor que atienda a todos sus usuarios; tener un servidor más pequeño para cada red para atender solo a sus clientes. Podrían compartir una fuente de datos común y esto también aliviaría la carga de su enrutador. Sin embargo, hay muchas formas de lograr una escala horizontal.
Espero que esto te ayude o te dé algunas ideas :)