Verifique a conectividade lan protegida
Agora que você configurou VLANs e polícias de segurança para proteger as comunicações das filiais locais, vamos confirmar rapidamente que a conectividade VLAN da filial funciona como esperado. O processo de validação é semelhante ao que você usou para validar a conectividade padrão. A principal diferença é que, agora, essas etapas de verificação ocorrem no contexto de uma VLAN/zona de segurança específica. E, é claro, dadas as mudanças de VLAN que você fez, você não espera mais conectividade total entre as portas LAN.
Verifique os servidores DHCP lan
Verifique se o SRX atribuiu endereços IP aos clientes LAN.
root@branch-srx> show dhcp server binding IP address Session Id Hardware address Expires State Interface 192.168.30.10 3543 08:81:f4:82:a4:5c 46482 BOUND irb.30 192.168.2.8 3538 08:81:f4:8a:eb:51 61414 BOUND irb.0 192.168.20.10 3542 20:4e:71:a6:a7:01 46622 BOUND irb.20 192.168.20.11 3544 d4:20:b0:00:c3:37 46621 BOUND irb.20
Observe que os dispositivos têm os mesmos endereços MAC de antes (veja a conectividade padrão SRX da filial), mas agora, eles estão associados a diferentes sub-redes IP e unidades IRB, com base em sua respectiva atribuição de VLAN. O display confirma que pelo menos um dispositivo está nas vlan-trustguestsVLANs e nas contractors VLANs. Esta saída confirma que seus servidores DHCP funcionam corretamente em cada VLAN.
Verifique sua configuração de VLAN.
root@branch-srx> show vlans
Routing instance VLAN name Tag Interfaces
default-switch contractors 30
ge-0/0/3.0*
default-switch default 1
default-switch guests 20
ge-0/0/1.0*
default-switch vlan-trust 3
ge-0/0/2.0*
...
A saída confirma que você configurou corretamente as VLANs e contractors as guests VLANs.
Verifique o VLAN dos convidados
Verifique se os dispositivos na guests VLAN e na zona podem acessar a Internet. Você confirma o acesso à Internet com um ping bem-sucedido para www.juniper.net. Lembre-se que o design de sua filial afirma que os hóspedes só podem enviar HTTP/HTTPS e tráfego de ping para a Internet.
user@guest-device> ping www.juniper.net inet count 2 PING e1824.dscb.akamaiedge.net (104.100.54.237): 56 data bytes 64 bytes from 104.100.54.237: icmp_seq=0 ttl=46 time=5.323 ms 64 bytes from 104.100.54.237: icmp_seq=1 ttl=46 time=6.204 ms --- e1824.dscb.akamaiedge.net ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 5.323/5.764/6.204/0.441 ms
Se o seu guests dispositivo de zona oferece suporte a um cliente HTTP de linha de comando, como o CURL, use-o para verificar o acesso HTTP à Internet. Você sempre pode usar um navegador da Web se o dispositivo tiver uma interface GUI para testar a conectividade da Web.
user@guest-device curl --head www.juniper.net HTTP/1.1 301 Moved Permanently Content-Type: text/html Location: https://www.juniper.net/ Content-Length: 0 Date: Mon, 18 Apr 2022 22:32:15 GMT Connection: keep-alive
Não nos preocuparemos em tentar encontrar uma máquina conectada à Internet para confirmar que todos os outros serviços, ou seja, SSH, Telnet, FTP, e assim por diante não funcionarão. Uma opção aqui é remover temporariamente a regra de política que permite o guests ICMP da zona para a untrust zona. Uma vez que a mudança entra em vigor, o ping www.juniper.net deve ter um tempo de saída.
Terminaremos de validar o guests VLAN confirmando que os dispositivos convidados não podem colocar a interface IRB nas zonas ou contractors nas trust zonas.
user@guest-device> ping 192.168.2.1 count 1 PING 192.168.2.1 (192.168.2.1): 56 data bytes --- 192.168.2.1 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss user@guest-device ping 192.168.30.1 count 1 PING 192.168.30.1 (192.168.30.1): 56 data bytes --- 192.168.30.1 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss
Os pings nas interfaces IRB nas zonas e contractors nas trust zonas falham, como esperado. Embora não sejam mostrados, os pings iniciados de hóspedes para estações finais nas trust zonas contractors também falham. Mais uma vez, você precisa de uma política explícita para permitir que o tráfego flua entre zonas. Para usuários convidados, a única política de segurança em vigor é permitir tráfego DE HTTP e ping para a untrust zona.
Validar o VLAN do funcionário
Verifique se os funcionários da trust zona podem acessar a Internet.
user@employee-device> ping www.juniper.net inet count 2 PING e1824.dscb.akamaiedge.net (104.100.54.237): 56 data bytes 64 bytes from 104.100.54.237: icmp_seq=0 ttl=44 time=4.762 ms 64 bytes from 104.100.54.237: icmp_seq=1 ttl=44 time=5.075 ms --- e1824.dscb.akamaiedge.net ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 4.762/4.918/5.075/0.157 ms
Verifique se os funcionários podem consultar os contratados.
user@employee-device> ping 192.168.30.10 PING 192.168.30.10 (192.168.30.10): 56 data bytes --- 192.168.30.10 ping statistics --- 38 packets transmitted, 0 packets received, 100% packet loss
A saída mostra que o ping não é bem-sucedido. Veja problemas de conectividade de depuração para obter informações sobre como depurar esse problema.
Problemas de conectividade de depuração
Vamos tentar depurar a questão de os funcionários não conseguirem colocar os contratados. Usaremos rastreamentos para depurar o fluxo de pacotes à medida que os pacotes atravessam da trust zona até a contractors zona. No mínimo, a traceoptions configuração deve incluir um arquivo alvo e uma bandeira. O argumento para o file comando especifica o nome do arquivo que armazena a saída de rastreamento. O(s) argumento(s) para o flag comando define o tipo de eventos a serem rastreados.
[edit] root@branch-srx# set security flow traceoptions file flow-debug root@branch-srx# set security flow traceoptions flag basic-datapath root@branch-srx# commit
Com o rastreamento ativado, gere pings da trust zona até a contractors zona. Embora os pings estejam falhando, use o show log <log_name> comando CLI junto com o find switch para localizar rapidamente áreas de interesse no arquivo de log de rastreamento.
root@branch-srx> show log flow-debug | find 192.168.30 Apr 20 03:22:36 03:22:36.712246:CID-0:RT:flow_ipv4_rt_lkup success 192.168.30.1, iifl 0x48, oifl 0x0 Apr 20 03:22:36 03:22:36.712246:CID-0:RT:flow_first_routing: setting out_vrf_id in lpak to 0, grp 0 Apr 20 03:22:36 03:22:36.712246:CID-0:RT:Changing out-ifp from .local..0 to irb.30 for dst: 192.168.30.1 in vr_id:0 Apr 20 03:22:36 03:22:36.712246:CID-0:RT: routed (x_dst_ip 192.168.30.1) from trust (irb.0 in 0) to irb.30, Next-hop: 192.168.30.1 Apr 20 03:22:36 03:22:36.712246:CID-0:RT:Policy lkup: vsys 0 zone(7:trust) -> zone(9:contractors) scope:0 src vrf (0) dsv vrf (0) scope:0 Apr 20 03:22:36 03:22:36.712246:CID-0:RT: 192.168.2.2/2048 -> 192.168.30.1/34912 proto 1 Apr 20 03:22:36 03:22:36.712246:CID-0:RT:Policy lkup: vsys 0 zone(5:global) -> zone(5:global) scope:0 src vrf (0) dsv vrf (0) scope:34912 Apr 20 03:22:36 03:22:36.712246:CID-0:RT: 192.168.2.2/2048 -> 192.168.30.1/34912 proto 1 Apr 20 03:22:36 03:22:36.712246:CID-0:RT:flow_first_policy_search: policy search from zone trust-> zone contractors (0x0,0x3d56010a,0x10a), result: 0xfa3c538, pending: 0? Apr 20 03:22:36 03:22:36.712246:CID-0:RT:flow_first_policy_search: dynapp_none_policy: TRUE, uc_none_policy: TRUE, is_final: 0x0, is_explicit: 0x0, policy_meta_data: 0x0 Apr 20 03:22:36 03:22:36.712246:CID-0:RT: app 0, timeout 60s, curr ageout 60s Apr 20 03:22:36 03:22:36.712246:CID-0:RT: packet dropped, denied by policy Apr 20 03:22:36 03:22:36.712246:CID-0:RT: denied by policy default-policy-logical-system-00(2), dropping pkt Apr 20 03:22:36 03:22:36.712246:CID-0:RT: packet dropped, policy deny. . . .
As entradas destacadas confirmam que o tráfego de teste enviado da trust zona para a contractors zona está sendo descartado. A mensagem diz denied by policy default-policy-logical-system o que indica que não há uma política para permitir esse tráfego.
Você deve ter uma política para permitir que o tráfego flua entre zonas. Adicione a configuração abaixo para configurar uma política de segurança que permita os tipos de tráfego desejados entre a trust zona e a contractors zona. A configuração está no formato de configuração rápida, de modo que você pode simplesmente cole-la no SRX da filial na [edit] hierarquia:
set security policies from-zone trust to-zone contractors policy trust-to-contractors match source-address any set security policies from-zone trust to-zone contractors policy trust-to-contractors match destination-address any set security policies from-zone trust to-zone contractors policy trust-to-contractors match application junos-http set security policies from-zone trust to-zone contractors policy trust-to-contractors match application junos-ping set security policies from-zone trust to-zone contractors policy trust-to-contractors then permit
Certifique-se de confirmar suas mudanças. Agora, o ping da trust zona para a contractors zona deve ter sucesso. Agora que sua depuração está completa, remova a configuração de rastreamento de fluxo de segurança.
[edit] root@branch-srx# delete security flow traceoptions root@branch-srx# commit
Contratantes VLAN
Verifique se os contratados não podem se comunicar com os clientes nas trust zonas ou guests zonas.
Apenas o ping na interface IRB (irb.30) deve ter sucesso. Como os endereços IP do cliente podem mudar com atribuições de DHCP atualizadas, optamos por testar a conectividade entre zonas, pingando a interface IRB para uma determinada zona. Neste exemplo, os endereços IP atribuídos às interfaces IRB são estáticos e, portanto, não mudarão ao longo do tempo.
user@contractor-device> ping 192.168.30.1 count 2 PING 192.168.30.1 (192.168.30.1): 56 data bytes 64 bytes from 192.168.30.1: icmp_seq=0 ttl=64 time=0.929 ms 64 bytes from 192.168.30.1: icmp_seq=1 ttl=64 time=0.864 ms --- 192.168.30.1 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.829/0.866/0.929/0.036 ms
Como esperado, o ping de um dispositivo de zona de contratação para a interface IRB para a contractors zona é bem-sucedido. Agora, você verifica a falta de conectividade com as zonas e guests zonastrust. Consulte a conectividade de filial local segura para obter detalhes sobre os endereços atribuídos às interfaces IRB neste exemplo.
user@contractor-device> ping 192.168.2.1 count 2 PING 192.168.2.1 (192.168.2.1): 56 data bytes --- 192.168.2.1 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss
user@contractor-device> ping 192.168.20.1 count 2 PING 192.168.20.1 (192.168.20.1): 56 data bytes --- 192.168.20.1 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss
A saída mostra que apenas o ping de 192.168.30.1 (atribuído ao irb.30) é bem-sucedido. Isso confirma que os contratados não podem acessar as zonas e guests as trust zonas.
Confirme que os contratados não podem acessar a Internet.
user@contractor-device> ping www.juniper.net inet count 1 ping: cannot resolve www.juniper.net: Host name lookup failure user@contractor-device> ping 8.8.8.8 count 1 PING 8.8.8.8 (8.8.8.8): 56 data bytes --- 8.8.8.8 ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss
Observe que a tentativa de ping www.juniper.net retorna uma mensagem de falha de busca de nome de host . Esta filial não tem um servidor DNS local e conta com um serviço de DNS público que só pode ser alcançado pela Internet. A falha na resolução do nome do host é uma boa indicação de que os contratados estão corretamente bloqueados do acesso à Internet. Como confirmação final, ping o servidor DNS público por seu endereço IP. Mais uma vez, o ping falha como esperado.
Esses resultados completam a validação da conectividade local segura da filial. Muito bom trabalho! Na próxima etapa, mostraremos como estabelecer uma conectividade segura pela Internet.