セキュアな LAN 接続の確認
ローカルブランチ通信を保護するためにVLANとセキュリティポリシーを設定したので、ブランチVLAN接続が期待通りに機能することを迅速に確認します。検証プロセスは、デフォルトの接続を検証するために使用したプロセスと似ています。主な違いは、これらの検証手順は特定の VLAN/セキュリティ ゾーンのコンテキストで行われるということです。そしてもちろん、行った VLAN の変更を考えると、LAN ポート間の完全な接続が必要ではなくなります。
LAN DHCP サーバーの検証
SRX に LAN クライアントに IP アドレスが割り当てられていることを確認します。
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
デバイスの MAC アドレスは以前と同じであることに注意してください( 「支社向け SRX のデフォルト接続」を参照)。ただし、対応する VLAN の割り当てに基づいて、デバイスは異なる IP サブネットと IRB ユニットに関連付けられます。このディスプレイは、少なくとも1つのデバイスが vlan-trust、 、 、 guestsおよび contractors VLANにあるか確認します。この出力は、各 VLAN 内で DHCP サーバーが正しく機能していることを確認します。
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*
...
出力では、 と contractors の VLAN が正しく設定guestsされていることを確認します。
ゲスト VLAN の検証
VLAN とゾーン内のデバイスが guests インターネットにアクセスできることを確認します。インターネット へのアクセスを確認し、ping を正常に www.juniper.net。支社の設計では、ゲストが HTTP/HTTPS および ping トラフィックをインターネットに送信することのみが許可されていることを思い出してください。
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
guestsゾーン デバイスで CURL などのコマンド ライン HTTP クライアントがサポートされている場合は、このクライアントを使用してインターネットへの HTTP アクセスを検証します。デバイスにGUIインターフェイスがある場合は、常にWebブラウザを使用して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
他のすべてのサービス(SSH、Telnet、FTPなど)が機能しないと確認するために、インターネットに接続されたマシンを見つけることは気にしません。ここでの 1 つのオプションは、ゾーン間で ICMP を許可するポリシー ルールを guests 一時的に削除することです untrust 。変更が有効になると、ping は www.juniper.net タイムアウトするはずです。
ゲストデバイスが または contractors ゾーンのいずれかでIRBインターフェイスに ping を実行できないことを確認して、VLANの検証guestsをtrust終了します。
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
および contractors ゾーンの trust IRB インターフェイスへの ping は、想定通りに失敗します。表示されていませんが、 または contractors ゾーン内trustのゲストからエンド ステーションへの ping も失敗します。繰り返しになりますが、ゾーン間のトラフィックの流れを許可する明示的なポリシーが必要です。ゲスト ユーザーの場合、有効な唯一のセキュリティ ポリシーは、ゾーンへの HTTP および ping トラフィックをuntrust許可することです。
従業員 VLAN の検証
ゾーン内の従業員がインターネットに trust アクセスできることを確認します。
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
従業員が請負業者に ping を実行できることを確認します。
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
出力は ping が成功しなかったことを示しています。この 問題をデバッグ する方法については、 接続の問題のデバッグを参照してください。
接続に関する問題のデバッグ
従業員が請負業者に ping を実行できないという問題をデバッグしてみましょう。traceoptions を使用して、パケットがゾーンからゾーンに通過するパケット フローをtrustcontractorsデバッグします。少なくとも、設定にはtraceoptionsターゲットファイルとフラグを含める必要があります。コマンドの引数は、fileトレース出力を格納するファイル名を指定します。コマンドのflag引数は、トレースするイベントのタイプを定義します。
[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
トレースがアクティブになると、ゾーンから trust ゾーンへの contractors ping が生成されます。ping が失敗している間、CLI コマンドを show log <log_name> スイッチとともに find 使用して、トレース ログ ファイル内の関心領域を迅速に特定します。
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. . . .
ハイライトされたエントリーは、ゾーンから trust ゾーンに contractors 送信されたテストトラフィックがドロップされていることを確認します。このメッセージには denied by policy default-policy-logical-system 、このトラフィックを許可するポリシーが示されていないというメッセージが表示されます。
ゾーン間をトラフィックが流れるようにするポリシーが必要です。ゾーンとゾーン間で必要なトラフィックタイプを許可するセキュリティポリシーを設定するには、以下の設定をtrustcontractors追加します。この構成はクイック構成セット形式であるため、 階層にあるブランチ SRX [edit] に貼り付けるだけです。
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
変更は必ずコミットしてください。これで、ゾーンから trust ゾーンへの ping は contractors 成功するはずです。デバッグが完了したら、セキュリティー フローの traceoptions 構成を削除します。
[edit] root@branch-srx# delete security flow traceoptions root@branch-srx# commit
請負業者 VLAN
請負業者がまたはguestsゾーン内のクライアントと通信できないことをtrust確認します。
IRB インターフェイス(irb.30)への ping のみが成功するはずです。クライアント IP アドレスは更新された DHCP 割り当てで変更される可能性があるため、特定のゾーンの IRB インターフェイスに ping を実行して、ゾーン間接続をテストすることを選択します。この例では、IRB インターフェイスに割り当てられた IP アドレスは静的であるため、時間の経過とともに変更されることはありません。
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
想定通り、請負業者ゾーン デバイスからゾーンの IRB インターフェイスへの ping にcontractors成功します。では、および guests ゾーンへの接続性の欠如をtrust検証します。この例では、IRB インターフェイスに割り当てられたアドレスの詳細については、 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
出力では、192.168.30.1(irb.30 に割り当てられた)への ping のみが正常であることを示しています。これにより、請負業者が および guests ゾーンにアクセスできないことがtrust確認されます。
請負業者がインターネットにアクセスできないことを確認します。
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
ping www.juniper.net を試みると、 ホスト名ルックアップ 失敗メッセージが返されていることに注意してください。この支社にはローカルの DNS サーバーはなく、インターネット上でのみ到達可能なパブリック DNS サービスに依存しています。ホスト名の解決に失敗した場合、コントラクターがインターネットアクセスから正しくブロックされていることを示しています。最終確認として、パブリック DNS サーバーの IP アドレスを ping します。繰り返しになりますが、ping は想定通りに失敗します。
これにより、支社のセキュアなローカル接続が完全に検証されます。よく出来ました！次のステップでは、インターネット上でセキュアな接続を確立する方法について説明します。