Verificar la conectividad LAN segura
Ahora que configuró las VLAN y las policías de seguridad para proteger las comunicaciones de las sucursales locales, confirmemos rápidamente que la conectividad VLAN de la sucursal funciona como se esperaba. El proceso de validación es similar al que utilizó para validar la conectividad predeterminada. La principal diferencia es que, ahora, estos pasos de verificación se producen en el contexto de una VLAN/zona de seguridad específica. Y, por supuesto, dados los cambios de VLAN que hizo, ya no espera una conectividad completa entre los puertos LAN.
Verificar servidores DHCP LAN
Verifique que el SRX haya asignado direcciones IP a los 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 los dispositivos tienen las mismas direcciones MAC que antes (consulte Conectividad predeterminada SRX de sucursal), pero que ahora están asociados con diferentes subredes IP y unidades IRB, según su respectiva asignación de VLAN. La pantalla confirma que al menos un dispositivo está en vlan-trustlas , las guests, y las contractors VLAN. Este resultado confirma que los servidores DHCP funcionan correctamente en cada VLAN.
Verifique su configuración 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*
...
El resultado confirma que ha configurado correctamente las guests VLAN y contractors .
Verificar la VLAN de invitados
Verifique que los dispositivos de la guests VLAN y la zona puedan tener acceso a Internet. Usted confirma el acceso a Internet con un ping correcto para www.juniper.net. Recuerde que el diseño de su sucursal indica que los invitados solo pueden enviar HTTP/HTTPS y ping de tráfico 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
Si su guests dispositivo de zona admite un cliente HTTP de línea de comandos, como CURL, úselo para verificar el acceso HTTP a Internet. Siempre puede usar un navegador web si el dispositivo tiene una interfaz GUI para probar la conectividad 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
No nos molestaremos en tratar de encontrar una máquina conectada a Internet para confirmar que todos los demás servicios, es decir, SSH, Telnet, FTP, etc. no funcionarán. Una opción aquí es quitar temporalmente la regla de política que permite ICMP de la guests zona a untrust . Una vez que el cambio se haga efectivo, el ping a www.juniper.net debe demorar.
Terminaremos de validar la VLAN confirmando que los guests dispositivos invitados no pueden hacer ping a la interfaz IRB en las trust zonas o contractors .
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
Los pings a las interfaces IRB en las trust zonas y contractors fallan, como se esperaba. Aunque no se muestra, los ping iniciados desde los invitados a las estaciones finales de las trust zonas o contractors también fallan. Una vez más, necesita una política explícita para permitir que el tráfico fluya entre zonas. Para los usuarios invitados, la única política de seguridad vigente es permitir el tráfico HTTP y ping a la untrust zona.
Validar la VLAN de los empleados
Verifique que los empleados de la trust zona puedan acceder 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 que los empleados puedan hacer ping a los contratistas.
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
El resultado muestra que el ping no es correcto. Consulte Depurar problemas de conectividad para obtener información sobre cómo depurar este problema.
Depurar problemas de conectividad
Intentemos depurar el problema de que los empleados no pueden hacer ping a los contratistas. Usaremos las evaluaciones de seguimiento para depurar el flujo de paquetes a medida que los paquetes atraviesan de la trust zona a la contractors zona. Como mínimo, la traceoptions configuración debe incluir un archivo de destino y una marca. El argumento al file comando especifica el nombre de archivo que almacena la salida del seguimiento. El argumento(s) del flag comando define el tipo de eventos que se van a rastrear.
[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
Con el rastreo activado, genere pings desde la trust zona a la contractors zona. Mientras los pings fallan, utilice el comando de la show log <log_name> CLI junto con el find conmutador para localizar rápidamente las áreas de interés en el archivo de registro de seguimiento.
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. . . .
Las entradas destacadas confirman que el tráfico de prueba enviado desde la trust zona a la contractors zona se está cayendo. El mensaje dice lo denied by policy default-policy-logical-system que indica que no hay una política que permita este tráfico.
Debe tener una política para permitir que el tráfico fluya entre zonas. Agregue la siguiente configuración para configurar una política de seguridad que permita los tipos de tráfico deseados entre la trust zona y la contractors zona. La configuración está en formato conjunto de configuración rápida, por lo que puede simplemente pegarla en el SRX de la sucursal en la [edit] jerarquía:
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
Asegúrese de confirmar los cambios. Ahora, el ping de la trust zona a la contractors zona debería tener éxito. Ahora que la depuración está completa, elimine la configuración de seguimiento de flujo de seguridad.
[edit] root@branch-srx# delete security flow traceoptions root@branch-srx# commit
VLAN de contratistas
Verifique que los contratistas no puedan comunicarse con los clientes en las trust zonas o guests .
Solo el ping a la interfaz IRB (irb.30) debe tener éxito. Dado que las direcciones IP del cliente pueden cambiar con las asignaciones DHCP actualizadas, optamos por probar la conectividad entre zonas haciendo ping a la interfaz IRB para una zona determinada. En este ejemplo, las direcciones IP asignadas a las interfaces IRB son estáticas y, por lo tanto, no cambian con el tiempo.
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 se esperaba, el ping desde un dispositivo de zona de contratista a la interfaz IRB para la contractors zona se hace correctamente. Ahora, verifica la falta de conectividad con las trust zonas y guests . Consulte Conectividad segura de sucursal local para obtener detalles sobre las direcciones asignadas a las interfaces IRB en este ejemplo.
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
El resultado muestra que solo el ping a 192.168.30.1 (asignado a irb.30) es correcto. Esto confirma que los contratistas no pueden acceder a las trust zonas y guests .
Confirme que los contratistas no pueden acceder 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 el intento de ping www.juniper.net devuelve un mensaje de error de búsqueda de nombre de host . Esta sucursal no tiene un servidor DNS local y depende de un servicio DNS público al que solo se puede acceder a través de Internet. La falla al resolver el nombre de host es una buena indicación de que los contratistas están correctamente bloqueados del acceso a Internet. Como confirmación final, haga ping al servidor DNS público por su dirección IP. Una vez más, el ping falla como se esperaba.
Estos resultados completan la validación de la conectividad local segura de la sucursal. ¡Buen trabajo! En el siguiente paso, le mostraremos cómo establecer una conectividad segura a través de Internet.