HP Procurve 5406zl - problema ACL


7

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!


Eu estou tentando bloquear o ping icmp entre vlans específicas, quando aplico a mesma configuração no Cisco seu achado de trabalho, mas quando experimentá-lo na série hp5400, ele não está funcionando. Digamos: Vlan-10 (192.168.10.1/24) Vlan-20 (192.168.20.1/24) A configuração de amostra seria a seguinte: # lista de acesso IP estendida "130" 10 negam icmp 192.168.10.0 255.255.255.0 192.168.20.0 255.255.255.0 20 permite ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 Vlan 10 grupo de acesso IP 10 130 in Favor informar !!!!!
khan

Respostas:


7

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.

ip access-list extended "SecureContent"
    10 permit ip 192.168.101.0 0.0.0.255 192.168.50.0 0.0.0.255

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.

ip access-list extended "SecureContent"
    10 permit ip 192.168.101.0 0.0.0.255 192.168.50.0 0.0.0.255
    20 permit ip 192.168.50.0 0.0.0.255 192.168.101.0 0.0.0.255

EDITADO para alterar a linha acima para refletir a estrutura ACL adequada das entradas numeradas. (10, 20, etc.)


Interessante - os dispositivos HP lidam com essa lógica da ACL de maneira totalmente diferente do material da Cisco. Obrigado por suas idéias. Vou tentar isso!
Panther Modern

11
Quais são as diferenças que você está encontrando? Minha formação é principalmente com equipamentos da Cisco e eu não encontrar esta configuração muito diferente ...
Daniel Yuste Aroca

Todas as minhas ACLs no equipamento Cisco funcionam sem as entradas para o tráfego de retorno.
Panther Modern

Para esclarecer: nunca tive que criar ACLs de tráfego de retorno no equipamento Cisco, exceto nos firewalls Pix mais antigos. Todas as ACLs do switch parecem funcionar bem com as entradas únicas que eu uso.
Panther Modern

11
Obrigado por confirmação Panther Modern, eu editei resposta novamente para torná-lo certo de acordo com a sua experiência
Daniel Yuste Aroca

2

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.

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.