Estou tendo um problema com uma ACL em uma interface VLAN. Segui a documentação da HP aqui: http://h20628.www2.hp.com/km-ext/kmcsdirect/emr_na-c02609963-3.pdf
Eu quero fazer o seguinte:
A VLAN 101 deve ser capaz de se comunicar apenas com a VLAN 50 - sem outras VLANs, sem acesso à Internet.
Inicialmente, tentei a seguinte lista de acesso:
ip access-list extended "SecureContent"
10 permit ip 192.168.50.0 0.0.0.255 192.168.101.0 0.0.0.255
20 remark "SecurityVLAN"
Eu apliquei esta ACL à VLAN 101 "in" com o seguinte comando:
vlan 101
ip access-group "SecureContent" in
Essa configuração resulta em comunicação zero nessa VLAN: O IP de 192.168.101.2 na porta A1 não pode executar ping em 192.168.101.1, o IP da VLAN do switch. Se eu alterar a lista de acesso para:
10 permit ip 192.168.101.1 0.0.0.255 192.168.101.1 0.0.0.255
20 permit ip 192.168.50.1 0.0.0.255 192.168.101.1 0.0.0.255
... isso resulta em clientes na VLAN capazes de executar ping no gateway padrão, mas não no gateway 50.1. Isso não faz sentido para mim - a interface IP da VLAN 101 deve ser considerada logicamente "dentro" daquela VLAN 101, correto?
Eu tentei várias versões dessa lista de acesso, chegando a fazer apenas uma lista de acesso padrão que bloqueia um único IP e, ao mesmo tempo, permite todo o resto com uma instrução "permitir ip qualquer qualquer" - e isso ainda resulta em zero inter ou intra- tráfego vlan - o host nessa VLAN não pode nem mesmo executar ping no seu próprio gateway se eu aplicar a lista na direção de entrada (eu também tentei uma variante na direção de saída - exatamente o mesmo resultado!)
Abaixo está a configuração do switch:
Running configuration:
; J8697A Configuration Editor; Created on release #K.15.09.0012
; Ver #03:01.1f.ef:f2
hostname "HP-5406zl"
module 1 type j8702a
module 2 type j8708a
module 3 type j9546a
module 4 type j8708a
power-over-ethernet pre-std-detect
ip access-list extended "SecureContent"
10 permit ip 192.168.101.1 0.0.0.255 192.168.101.1 0.0.0.255
20 permit ip 192.168.50.1 0.0.0.255 192.168.101.1 0.0.0.255
exit
ip route 0.0.0.0 0.0.0.0 172.16.0.1
ip routing
snmp-server community "public" unrestricted
snmp-server contact "Person" location "Place"
vlan 1
name "DEFAULT_VLAN"
no untagged A1-A20,A23-A24,B1-B4,C1-C8,D1-D4
untagged A21-A22
ip address 192.168.1.10 255.255.255.0
jumbo
exit
vlan 50
name "Editors"
untagged A2-A19,B1-B3,C1-C8,D1-D4
tagged A23-A24
ip address 192.168.50.1 255.255.255.0
jumbo
exit
vlan 100
name "IO"
tagged A23-A24
ip address 192.168.100.1 255.255.255.0
exit
vlan 101
name "SecureContent"
untagged A1
ip address 192.168.101.1 255.255.255.0
ip access-group “SecureContent” in
exit
vlan 200
name "Corp"
tagged A23-A24
ip address 192.168.200.1 255.255.255.0
ip helper-address 192.168.50.2
exit
vlan 800
name "IT"
untagged A23-A24
ip address 172.17.0.1 255.255.255.0
exit
vlan 899
name "DMZ"
untagged B4
tagged A23-A24
ip address 172.18.0.1 255.255.255.0
jumbo
exit
vlan 900
name "Routed"
untagged A20
tagged A23-A24
ip address 172.16.0.2 255.255.255.252
exit
vlan 999
name "VLAN999"
no ip address
exit
EDITADO para adicionar informações relevantes do chassi:
Software revision : K.15.09.0012 Base MAC Addr : 002561-f80000
ROM Version : K.15.30 Serial Number : XXXXXXXX
Allow V1 Modules : Yes
Opacity Shields : Not Installed
Agradeço antecipadamente por sua ajuda!
fonte
Respostas:
De acordo com o Access Security Guide para seu dispositivo, o primeiro endereço e a máscara de um ACE são a origem e o segundo endereço e a máscara é o destino. (Apenas no caso, uma ACE é uma entrada de controle de acesso; ou seja, qualquer linha da qual seja feita uma lista de acesso)
O ACE 20 da origem dos estados da ACL 192.168.50.0/24 e destino 192.168.101.0/24, em seguida, você aplica a ACL na entrada da VLAN 101; no entanto, sua VLAN 101 é 192.168.101.0/24, portanto, qualquer tráfego de entrada na VLAN 101 teria endereço de origem em 192.168.101.0/24. Portanto, o ACE 20 na sua ACL está errado, você precisa de um ACE com permissão de ação, origem 192.168.101.0/24 e destino 192.168.50.0/24.
Em relação ao caminho de volta para esse tráfego, ele cruzará a saída da VLAN 101, portanto a ACL não deve ser aplicada a esse tráfego e deve ser permitida.
Se o tráfego de retorno não for permitido, será necessário adicionar o caminho de volta à sua ACL.
EDITADO para alterar a linha acima para refletir a estrutura ACL adequada das entradas numeradas. (10, 20, etc.)
fonte
Parece que esse problema se deve à maneira como o equipamento de rede da HP lida com ACLs versus Cisco (que é o meu plano de rede).
De acordo com este documento, as ACLs da HP são sem estado e devem conter entradas de tráfego bidirecionais (para tráfego de origem e retorno): http://tinyurl.com/qbfemk6 (link para PDF no site da HP).
Isso contrasta com o guia Gerenciamento avançado de tráfego acima, que exibe exemplos de configuração que não implementam ou respondem a essa "peculiaridade": os exemplos não contêm essas entradas de tráfego de retorno.
Lições aprendidas: Não confie na documentação do fabricante para ser consistente e precisa.
fonte