Sichere LAN-Konnektivität überprüfen
Jetzt, da Sie VLANs und Sicherheitsrichtlinien für den Schutz der Kommunikation in den lokalen Zweigstellen konfiguriert haben, können wir schnell bestätigen, dass die VLAN-Konnektivität für Zweigstellen wie erwartet funktioniert. Der Validierungsprozess ähnelt dem, den Sie zur Validierung der Standardkonnektivität verwendet haben. Der Hauptunterschied besteht darin, dass diese Überprüfungsschritte jetzt im Kontext einer bestimmten VLAN/Sicherheitszone erfolgen. Und angesichts der VLAN-Änderungen, die Sie vorgenommen haben, erwarten Sie natürlich keine vollständige Konnektivität zwischen den LAN-Ports mehr.
LAN-DHCP-Server überprüfen
Stellen Sie sicher, dass die SRX den LAN-Clients IP-Adressen zugewiesen hat.
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
Beachten Sie, dass die Geräte dieselben MAC-Adressen wie zuvor haben (siehe Branch SRX Default Connectivity), aber jetzt werden sie je nach VLAN-Zuweisung verschiedenen IP-Subnets und IRB-Einheiten zugeordnet. Die Anzeige bestätigt, dass sich mindestens ein Gerät in den vlan-trust, den und den contractors guestsVLANs befindet. Diese Ausgabe bestätigt, dass Ihre DHCP-Server in jedem VLAN ordnungsgemäß funktionieren.
Überprüfen Sie Ihre VLAN-Konfiguration.
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*
...
Die Ausgabe bestätigt, dass Sie die guests VLANs contractors richtig konfiguriert haben.
Überprüfen sie das Gäste-VLAN
Stellen Sie sicher, dass Geräte im VLAN und in der guests Zone auf das Internet zugreifen können. Sie bestätigen den Internetzugang mit einem erfolgreichen Ping an www.juniper.net. Erinnern Sie sich daran, dass Gäste in Ihrer Zweigstelle nur HTTP/HTTPS- und Ping-Datenverkehr an das Internet senden dürfen.
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
Wenn Ihr guests Zonengerät einen BEFEHLSZEILEN-HTTP-Client wie CURL unterstützt, verwenden Sie diesen, um den HTTP-Zugriff auf das Internet zu überprüfen. Sie können immer einen Webbrowser verwenden, wenn das Gerät über eine GUI-Schnittstelle zum Testen der Webkonnektivität verfügt.
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
Wir werden uns keine Mühe machen, einen mit dem Internet verbundenen Computer zu finden, um zu bestätigen, dass alle anderen Services, also SSH, Telnet, FTP usw., nicht funktionieren. Eine Option ist es, die Richtlinienregel, die ICMP von der guests Zone zulässt, vorübergehend zu untrust entfernen. Sobald die Änderung wirksam wird, sollte der Ping auf www.juniper.net time-out.
Wir beenden die Validierung des guests VLANs, indem wir bestätigen, dass Gastgeräte die IRB-Schnittstelle weder in der Zone noch contractors in der trust Zone pingen können.
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
Die Pings zu den IRB-Schnittstellen in den trust Und contractors Zonen schlagen wie erwartet fehl. Obwohl nicht angezeigt, Pings, die von Gästen an Endstationen in den trust oder contractors Zonen initiiert werden, ausfallen auch. Auch hier benötigen Sie eine explizite Richtlinie, um den Datenverkehr zwischen Zonen zu ermöglichen. Für Gastbenutzer besteht die einzige Sicherheitsrichtlinie darin, HTTP- und Ping-Datenverkehr zur Zone zuzulassen untrust .
Mitarbeiter-VLAN validieren
Stellen Sie sicher, dass die Mitarbeiter in der trust Zone auf das Internet zugreifen können.
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
Stellen Sie sicher, dass die Mitarbeiter den Auftragnehmern pingen können.
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
Die Ausgabe zeigt, dass der Ping nicht erfolgreich ist. Informationen zum Debuggen dieses Problems finden Sie unter Debuggen von Konnektivitätsproblemen .
Debuggen von Konnektivitätsproblemen
Lassen Sie uns versuchen, das Problem zu debuggen, dass die Mitarbeiter die Auftragnehmer nicht anpingen können. Wir verwenden Traceoptionen, um den Paketfluss zu debuggen, während die Pakete von der trust Zone zur contractors Zone überqueren. Die Konfiguration muss mindestens traceoptions eine Zieldatei und ein Flag enthalten. Das Argument für den file Befehl gibt den Dateinamen an, in dem die Trace-Ausgabe gespeichert wird. Die Argumente für den flag Befehl definieren den Typ der Ereignisse, die zurückverfolgt werden sollen.
[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
Wenn die Ablaufverfolgung aktiviert ist, generieren Sie Pings von der trust Zone zur contractors Zone. Während die Pings fehlschlagen, verwenden Sie den show log <log_name> CLI-Befehl zusammen mit dem find Switch, um schnell bereiche zu lokalisieren, die in der Traceprotokolldatei von Interesse sind.
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. . . .
Die hervorgehobenen Einträge bestätigen, dass der von der Zone in die trust contractors Zone gesendete Testverkehr unterbrochen wird. Die Meldung besagt denied by policy default-policy-logical-system , dass es keine Richtlinie gibt, um diesen Datenverkehr zu erlauben.
Sie benötigen eine Richtlinie, um den Datenverkehr zwischen Zonen zu ermöglichen. Fügen Sie die folgende Konfiguration hinzu, um eine Sicherheitsrichtlinie zu konfigurieren, die die gewünschten Datenverkehrstypen zwischen der trust Zone und der contractors Zone zulässt. Die Konfiguration ist im Schnellkonfigurations-Set-Format, sodass Sie sie einfach in die SRX-Zweigstelle in der [edit] Hierarchie einfügen können:
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
Stellen Sie sicher, dass Sie Ihre Änderungen vornehmen. Nun sollte der Ping von der trust Zone zur contractors Zone erfolgreich sein. Entfernen Sie jetzt nach Abschluss der Fehlerbehebung die Konfiguration der Sicherheitsfluss-Traceoptionen.
[edit] root@branch-srx# delete security flow traceoptions root@branch-srx# commit
Auftragnehmer VLAN
Stellen Sie sicher, dass die Auftragnehmer nicht mit den Clients in den trust Zonen kommunizieren guests können.
Nur der Ping zur IRB-Schnittstelle (irb.30) sollte erfolgreich sein. Da sich die Client-IP-Adressen mit aktualisierten DHCP-Zuweisungen ändern können, entscheiden wir uns dafür, die zonenübergreifende Konnektivität zu testen, indem wir die IRB-Schnittstelle für eine bestimmte Zone anpingen. In diesem Beispiel sind die DEN IRB-Schnittstellen zugewiesenen IP-Adressen statisch und ändern sich daher im Laufe der Zeit nicht.
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
Wie erwartet, ist der Ping von einem Gerät für die Auftragnehmerzone zur IRB-Schnittstelle für die contractors Zone erfolgreich. Jetzt überprüfen Sie die fehlende Konnektivität zu den trust Zonen. guests Weitere Informationen zu den Adressen, die den IRB-Schnittstellen in diesem Beispiel zugewiesen wurden, finden Sie unter Secure Local Branch Connectivity .
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
Die Ausgabe zeigt, dass nur der Ping an 192.168.30.1 (irb.30 zugewiesen) erfolgreich ist. Dadurch wird bestätigt, dass Auftragnehmer keinen Zugriff auf die trust Und guests Zonen haben.
Bestätigen Sie, dass die Auftragnehmer keinen Zugriff auf das Internet haben.
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
Beachten Sie, dass der Ping-Versuch www.juniper.net eine Fehlermeldung mit dem Fehler bei der Hostnamen-Suche zurückgibt. Diese Zweigstelle verfügt über keinen lokalen DNS-Server und ist auf einen öffentlichen DNS-Dienst angewiesen, der nur über das Internet erreichbar ist. Das Versäumnis, den Hostnamen zu lösen, ist ein guter Hinweis darauf, dass Auftragnehmer korrekt für den Internetzugang blockiert wurden. Als letzte Bestätigung pingen Sie den öffentlichen DNS-Server nach seiner IP-Adresse. Auch hier schlägt der Ping wie erwartet fehl.
Die Ergebnisse der vollständigen Validierung der sicheren lokalen Konnektivität der Zweigstelle. Gut Gemacht! Im nächsten Schritt zeigen wir Ihnen, wie Sie eine sichere Konnektivität über das Internet herstellen können.