[GTER] Usando Vlans

[casfre at gmail.com]

2009/2/18 Julio Arruda <jarruda-gter at jarruda.com>:
> bruno at openline.com.br wrote:
>>
>> --- "casfre at gmail.com" <casfre at gmail.com> escreveu:
>>>
>>>     Nesse caso, o que me deixa "encucado" ( "farta" (de) leitura, com
>>> já citei? ) é que o switch precisa de alguma coisa para saber o
>>> destino dos pacotes, já que a porta 1 é comum entre todas as VLANs.
>>> Pelo que o Júlio explicou, pode ser, por exemplo o MAC.
>>
>> Sim, no port based VLAN é o mac. No tag based é o ID da VLAN
>> no frame ethernet
>
> Na verdade nao, em uma porta com 802.1Q, pacotes entrantes sao CLASSIFICADOS
> em uma VLAN, pelo tag, mas o destino dos pacotes, ai vai cair na historia do
> MAC destino de novo, neste caso, na tabela de forwarding DAQUELA VLAN
> somente..Se for nao-unicast ou desconhecido, vai fazer flooding para todas
> as outras portas na mesma VLAN, se for conhecido o destino, vai sair somente
> por aquela porta.

     Li uma parte do livro que sugeriu (Radia Perlman sim). Na
verdade, o texto que li, apesar de curto, fala sobre VLANs. Acho que
eu devia ter usado a palavra "mapear".  O que eu busco entender é algo
que você citou em outra mensagem, ou seja: mapeamento por MAC, IP,
protocolo ou porta. Uma vez que há um, digamos, ìndice que o switch
usa, o resto depende do equipamento. Não me preocupei, ainda, com a
"entrega" do pacote depois que o switch determina a que VLAN ele
pertence.

     Segundo os manuais, os equipamentos a que tenho acesso só fazem
VLAN por porta e oferecem a opção de ter portas TAGGED e UNTAGGED,
sendo que a última usa 802.1q (VLAN ID) para "mapear" as VLANs. Assim,
para não usar um roteador com N+1 placas de rede (onde N é igual ao
número de VLANs +1 para o que eu chamo de "porta de backbone"), a
saída é usar um roteador com suporte a 802.1q e portas TAGGED. Por
definição, nesse caso, cada VLAN usa uma subnet diferente (o que
complica a vída para configurar um DCHP server central (já estou
testando dhcp relay). Esse complicador do DCHP, no entanto, já existe,
pois há N segmentos em switches diferentes e já usando outros
roteadores.

     Nesses equipamentos, há certas condições, como: uma porta para
fazer parte de mais de uma VLAN, ao mesmo tempo, precisa ser TAGGED,
ou seja, usa o VLAN ID. A VLAN1 é padrão e não pode ser excluída. A
monitoração do switch só ocorre por meio de porta(s) da VLAN1 e, nessa
VLAN, nehuma porta pode ser TAGGED. Por padrão, se uma porta não está
alocada a uma determinada VLAN, ela é UNTAGGED e faz parte da VLAN1 e
só deixa de fazer parte da

     Essas condições me deixaram com uma condição com a qual eu não
tinha lidado: a porta do roteador (GNU/Linux) com suporte a 802.1q
está ligada a uma porta que faz parte da VLAN1 ( UNTAGGED por
definição ). Essa porta é TAGGED em todas as outras VLANs. Essa foi a
única forma que encontrei para que todas as VLANs não se comuniquem
entre si e, ainda assim, possam usar uma porta comum para ter conexão
com o "mundo". Até aqui, tudo bem. No entanto, resolvi
monitorar/gerenciar o equipamento.

     No roteador (GNU/Linux), cada VLAN é designada para uma interface
virtual específica. Assim, a VLAN com ID 2 assume, por exemplo, a
interface eth1.2. Dessa forma, o roteador lida com o VLAN ID. No
entanto, como a monitoração/gerência só ocorre em portas da VLAN1, a
única forma de fazer tal gerência é alocar um IP (coerente com o IP do
switch) à interface "física" relacionada. No exemplo que citei, seria
eth1. Eu li, não sei quando não sei onde, que não é boa prática usa a
interface "física" com endereçamento quando ela é usada para VLANs.
Nesse caso, sem isso, a única forma seria adicionar uma outra placa ao
roteador apenas para gerência. Se o roteador está próximo ao switch,
tudo bem, mas e se ele está há vários metros e com local difícil para
passar cabos? Nesse caso, ainda estou pensando em alternativas...



>>>     Sim, esse foi o primeiro uso que fiz, embora eu não me sinta
>>> "seguro" usando VLANs para separar segmentos críticos
>>
>> Se colocar a vlan da configuração do switch no seguimento seguro
>> não tem como entrar nele (de fora) para alterar as VLANs e
>> ganhar acesso interno (pelo menos nenhum jeito que eu conheça)
>
> Creio que nao precisava, ao menos antigamente, procure por VLAN leaking..
> Por sinal, era a raiz do grande debate "VLANs sao seguras ou nao",
> sinceramente, nao lembro qual a conclusao, mas que dava para burlar as VLANs
> em alguns dispositivos, era esta a teoria..

     É, da última vez que o assunto circulou aqui na GTER, também
achei inconclusivo.