Quais são as implicações de ter duas sub-redes no mesmo switch?


36

Alguém pode me dizer quais seriam as implicações de ter duas sub-redes diferentes no mesmo switch se as VLANs não estivessem sendo usadas?


Nesse caso, o risco de falsificação não é um problema que me preocupa.
Kyle Brandt

2
Isso também é uma informação útil para administradores que migram uma rede para um novo intervalo de IPs.
Terence Johnson

Uma coisa a ser observada, que é encontrada em algumas das respostas abaixo, é que, a menos que você use VLAN ou endereçamento IP estático em seus clientes, todos eles receberão o DHCP do tipo "escopo" padrão.
Adam Nofsinger

Respostas:


25

As coisas vão funcionar da maneira que você esperaria. No centro disso, eles estão apenas compartilhando um domínio de transmissão. Os computadores nas diferentes sub-redes não ARP na sub-rede, então eles ainda precisarão de um roteador (ou entidade de camada 3 incorporada no comutador) para "conversar" entre si.

Como eles compartilham um domínio de broadcast, há muito menos (sem dúvida nenhum) isolamento do que se você estivesse usando VLANs. Seria fácil hospedar ARP e MAC spoof em qualquer uma das sub-redes.

Se você está fazendo isso apenas em um cenário de laboratório, provavelmente está bem. Porém, se você realmente precisa de isolamento na implantação de produção, use VLANs ou switches físicos separados.


É um ambiente de produção, mas a falsificação não é realmente um problema neste caso.
Kyle Brandt

1
Você diz isso até que seja. Atualize para switches que fazem VLANs ou compre outro switch. Sério.
Matt Simmons

Tem outro interruptor :-)
Kyle Brandt

12

Se você não usa VLANs, uma pessoa pode facilmente adicionar 2 IPs à sua interface, digamos, 192.182.0.1/24e 172.16.0.1/24assim ele pode acessar as duas redes.

Ao usar VLANs, você pode marcar as portas do switch para que qualquer computador configurado para receber apenas tráfego da VLAN não consiga obter nenhum tráfego (exceto aquele direcionado a ela e com a VLAN correta), independentemente de como a interface local esteja configurada ( quantos IPs existem na interface).

Em essência:

  • se você confia nos seus usuários, não há motivo para usar VLANs (do ponto de vista da segurança).
  • se você não confiar nos usuários, as VLANs manterão determinados grupos de usuários separados um do outro

8
VLANs não devem ser usadas para segurança. Eles são apenas para fins de gerenciamento. A Cisco tem um excelente white paper discutindo as implicações de segurança das VLANs. Veja: cisco.com/en/US/products/hw/switches/ps708/…
Joseph Kern

2
@JosephKern Você pode me dar um TLDR de por que não?
Kevin Wheeler

3
A VLAN @KevinWheeler oferece zero mecanismos de autenticação. Aqui está um artigo SANS com uma explicação mais longa: sans.org/reading-room/whitepapers/networkdevs/...
Joseph Kern

3

Primeiro, não sei por que você faria isso com os usuários. O único cenário em que consigo pensar é que você está sem IPs na sua sub-rede de usuário atual e não pode estender facilmente sua sub-rede atual. Nesse caso, acho que seria bom adicionar outra sub-rede. A questão da falsificação se torna um problema quando você está usando os IPs dessa maneira, porque ambas as sub-redes são iguais; portanto, você tem o mesmo risco de falsificação, usando uma única sub-rede ou várias. Uma pergunta que tenho aqui é como o DHCP funcionaria. Se seus escopos DHCP não forem contíguos e o servidor DHCP fornecer IPs com base no endereço "auxiliar" do roteador, todas as solicitações não serão direcionadas para um escopo ou outro? Suponho que isso possa se tornar um problema se o servidor DHCP estiver diretamente no domínio de broadcast, mas ainda há algo a explorar.

Tudo isso dito, eu realmente faço isso na produção de um dos meus aplicativos. Eu tenho um aplicativo que possui silos geograficamente diversos, cada silo tem seu / 27. Esses IPs são o que considero ser IPs de infraestrutura. Eles pertencem a esses servidores. Em seguida, direciono um / 29 adicional para o mesmo domínio de broadcast. Esta sub-rede pertence ao aplicativo. Na próxima atualização de hardware, construirei um silo totalmente novo com um / 27 novo e depois alterarei a rota do aplicativo / 29 para ele. Como este / 29 lida com a comunicação com elementos de rede, isso não permite reprogramar todos os NEs se obtivermos novo hardware ou novo software, e usar o mesmo domínio de broadcast permite que eu faça isso sem uma NIC dedicada.


O "porquê" é que nosso sistema ERP pos antigo e ruim que está sendo movido não pode alterar IPs sem reinstalar todos os clientes (e outros problemas do AD). Obrigado pela ideia do DHCP, vou ter que explorar esse problema.
Kyle Brandt

3
  1. se você tiver usuários não confiáveis ​​- alguns deles podem falsificar endereços IP daqueles de outras sub-redes. se houver algumas regras de endereço - elas podem ignorá-las. alguns usuários da sub-rede1 podem falsificar o endereço do roteador na rede b - e espionar [pelo menos parte da] comunicação.
  2. você terá mais 'lixo' de transmissão [pacotes arp] - mas isso não deve ser sua preocupação se você tiver poucas dezenas de usuários e um link de 100 ou 1000 Mbit / s.

0

Implementamos isso em nossa escola porque estávamos ficando sem endereços IP e demos uma nova sub-rede à seção sem fio, funciona bem em uma rede de 3.000 usuários, pois uma solução rápida é uma vantagem, concordo que precisamos criar vlans para preservar a segurança.

O servidor DHCP (Windows) deve ter duas placas de rede conectadas ao mesmo comutador (a nossa é virtual para que não importe) para fornecer ips à rede sem fio, você precisará usar IPs estáticos na "rede antiga" , ele não funcionará servindo dois escopos dhcp no mesmo comutador.


-3

Passei alguns anos tentando resolver um problema com um sistema de telefone poe e uma rede de computadores no mesmo switch gerenciado. Sim, ele deve funcionar sem uma VLAN, mas todos os meses, ou não, e redefiniria o comutador, causando problemas sem fim nos equipamentos conectados. (redefinições do sistema telefônico, redefinições do roteador e redefinições aleatórias do switch) Isso foi um pesadelo para nós, pois procurávamos um problema de hardware, pois a maioria aceita que um switch possa lidar com isso. Um interruptor estúpido, talvez, mas um switch gerenciado não. Eu tentei vários fabricantes importantes e todos eles seriam redefinidos aleatoriamente dentro de um mês :(

SEMPRE VLAN SEMPRE!

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.