Em resumo, os dispositivos que roteiam o tráfego entre suas várias sub-redes (atribuídas a várias VLANs) precisam impor a política de segurança de comunicação. No mínimo, isso significa usar roteadores (ou dispositivos com funcionalidade de roteador) que suportam listas de controle de acesso sem estado. Se você quiser ficar mais chique, você pode usar dispositivos com funcionalidade de filtragem de estado (firewalls stateful típicos, iptables do Linux, etc).
Acho que você pode ter uma concepção simplista do que significa não permitir que "usuários normais acessem a produção". O caminho que você está indo para baixo envolve a criação de gráficos dos vários protocolos (portas TCP e UDP, normalmente) com os quais os aplicativos clientes precisarão se comunicar nos computadores servidores (alguns dos quais, no caso do Microsoft RPC, são dinâmicos por padrão ). Depois de descobrir como essa comunicação deve funcionar, você cria listas de controle de acesso (ou regras de firewall) para permitir a comunicação necessária e, ao mesmo tempo, negar todo o tráfego.
Esta é uma linha dura para enxada. Eu vi poucos ambientes onde isso foi completamente pensado e implementado. Envolve um lote de comunicação entre os administradores do aplicativo e os administradores de rede (ou, se você é um no mesmo, muita documentação de software de estudo). Normalmente, será preciso fazer um lote de testes e, em muitos casos, você aprenderá que os desenvolvedores de aplicativos de software "boutique" nunca tiveram tempo de descobrir quais protocolos seus aplicativos usam para se comunicar (e muitas vezes apenas assumir uma rede aberta e plana entre o cliente e o servidor).
No final, você perceberá que terá mais sorte executando regras de firewall baseadas em host e sendo bastante tolerantes com suas listas de controle de acesso / regras de firewall dentro da VLAN, não necessariamente porque essa é a coisa certa a fazer, mas porque é a coisa viável a fazer. Boa sorte!
Como um aparte: Ver suas sub-redes planejadas aumentando em 10 no terceiro octeto diz a mesma coisa que sua declaração "Eu nunca projetei uma rede a partir do zero, por mim mesmo." Se você quiser permitir espaço para crescimento nessas sub-redes, considere fazer algo mais como:
- 10.10.0.0 / 19
- 10.10.32.0 / 19
- 10.10.64.0 / 19
- 10.10.96.0 / 19
Mesmo se você começar a usar essas várias sub-redes como / 24's, você terá espaço em cada uma para crescer até / 19's (com 4 / 19s disponíveis para uso futuro também). Com as sub-redes não contíguas que você está propondo em sua resposta, você está desperdiçando espaço de IP ou criando redes que não podem ser resumidas com uma única rota CIDR.