従来の設定から現在の vSRX 仮想ファイアウォール アーキテクチャへの移行
IBM Cloud™ Juniper vSRX 仮想ファイアウォール構成を従来のアーキテクチャから現在のアーキテクチャに移行するには、慎重に検討する必要があります。
vSRX仮想ファイアウォール18.4の導入では、ほとんどの場合、現在のアーキテクチャを活用しています。これには、vSRX仮想ファイアウォール18.4 1G SR-IOV製品が含まれます。古い vSRX 仮想ファイアウォール 18.4 1G 標準製品は Linux ブリッジングをベースにしており、Ubuntu ホスト、KVM ハイパーバイザー、vSRX 仮想ファイアウォール構成でさまざまなネットワーク構成を行っています。ホストと KVM の設定では、自動化プロセスが構成変更を処理するため、特別な移行手順は必要ありません。ただし、vSRX 仮想ファイアウォールの構成を従来のアーキテクチャから現在の vSRX 仮想ファイアウォール構成にインポートする場合は、一部の構成を再組み込む必要があります。
1G vSRX 仮想ファイアウォール スタンドアロン構成の移行
スタンドアロン 18.4 1G パブリック+プライベート Linux ブリッジ(レガシー アーキテクチャ)インスタンスの vSRX 仮想ファイアウォール構成設定をスタンドアロン 18.4 1G パブリック+プライベート SR-IOV(現在のアーキテクチャ)インスタンスに変換する必要があるステップがいくつかあります。SR-IOV ベースの現在のアーキテクチャのデフォルト 構成の例 1G スタンドアロン SR-IOV パブリックおよびプライベート vSRX ゲートウェイのデフォルト構成例を見つけることができます。
次に、Linux Bridge(レガシー アーキテクチャ)のデフォルト設定例を示します。この例では、異なるデータセンターポッドでプロビジョニングされたvSRX仮想ファイアウォールインスタンスを示しています。その結果、トランジット VLAN(native-vlan-id)は異なります。
## Last commit: 2020-04-16 22:48:33 UTC by root version 18.4R1-S1.3; system { login { class security { permissions [ security-control view-configuration ]; } user admin { uid 2000; class super-user; authentication { encrypted-password "$6$vKPIcB3I$XlDRg3Oto9tLa7zRPkalSfonrKUEJI7U16XX2lrke3k2sPaV.CY0CJhSBIPx5aXhqo7h1GWPhhMbv0Ce1WANO."; ## SECRET-DATA } } } root-authentication { encrypted-password "$6$cbXBMc8b$jHd6LtR4OjXvjmgubQXAlofNonk6lLbNPs35beda7ffEV4XKEUQiEf1XUA3mMvJv2V1YET3kiWBogqz8h2zB7."; ## SECRET-DATA } services { ssh { root-login allow; } netconf { ssh { port 830; } } web-management { http { interface fxp0.0; } https { port 8443; system-generated-certificate; interface [ fxp0.0 ge-0/0/0.0 ge-0/0/1.0 ]; } session { session-limit 100; } } } host-name asloma-e2e-tc15-18-1g-1270-sa-vsrx-vSRX; name-server { 10.0.80.11; 10.0.80.12; } syslog { user * { any emergency; } file messages { any any; authorization info; } file interactive-commands { interactive-commands any; } } ntp { server 10.0.77.54; } } security { log { mode stream; report; } address-book { global { address SL8 10.1.192.0/20; address SL9 10.1.160.0/20; address SL4 10.2.128.0/20; address SL5 10.1.176.0/20; address SL6 10.1.64.0/19; address SL7 10.1.96.0/19; address SL1 10.0.64.0/19; address SL2 10.1.128.0/19; address SL3 10.0.86.0/24; address SL20 10.3.80.0/20; address SL18 10.2.176.0/20; address SL19 10.3.64.0/20; address SL16 10.2.144.0/20; address SL17 10.2.48.0/20; address SL14 10.1.208.0/20; address SL15 10.2.80.0/20; address SL12 10.2.112.0/20; address SL13 10.2.160.0/20; address SL10 10.2.32.0/20; address SL11 10.2.64.0/20; address SL_PRIV_MGMT 10.129.33.87/32; address SL_PUB_MGMT 161.202.136.77/32; address-set SERVICE { address SL8; address SL9; address SL4; address SL5; address SL6; address SL7; address SL1; address SL2; address SL3; address SL20; address SL18; address SL19; address SL16; address SL17; address SL14; address SL15; address SL12; address SL13; address SL10; address SL11; } } } screen { ids-option untrust-screen { icmp { ping-death; } ip { source-route-option; tear-drop; } tcp { syn-flood { alarm-threshold 1024; attack-threshold 200; source-threshold 1024; destination-threshold 2048; queue-size 2000; ## Warning: 'queue-size' is deprecated timeout 20; } land; } } } policies { from-zone SL-PRIVATE to-zone SL-PRIVATE { policy Allow_Management { match { source-address any; destination-address [ SL_PRIV_MGMT SERVICE ]; application any; } then { permit; } } } from-zone SL-PUBLIC to-zone SL-PUBLIC { policy Allow_Management { match { source-address any; destination-address SL_PUB_MGMT; application [ junos-ssh junos-https junos-http junos-icmp-ping ]; } then { permit; } } } } zones { security-zone SL-PRIVATE { interfaces { ge-0/0/0.0 { host-inbound-traffic { system-services { all; } } } } } security-zone SL-PUBLIC { interfaces { ge-0/0/1.0 { host-inbound-traffic { system-services { all; } } } } } } } interfaces { ge-0/0/0 { description PRIVATE_VLANs; flexible-vlan-tagging; native-vlan-id 1214; unit 0 { vlan-id 1214; family inet { address 10.129.33.87/26; } } } ge-0/0/1 { description PUBLIC_VLAN; flexible-vlan-tagging; native-vlan-id 764; unit 0 { vlan-id 764; family inet { address 161.202.136.77/29; } family inet6 { address 2401:c900:1001:0210:0000:0000:0000:000a/64; } } } fxp0 { unit 0; } lo0 { unit 0 { family inet { filter { input PROTECT-IN; } address 127.0.0.1/32; } } } } firewall { filter PROTECT-IN { term PING { from { destination-address { 161.202.136.77/32; 10.129.33.87/32; } protocol icmp; } then accept; } term SSH { from { destination-address { 161.202.136.77/32; 10.129.33.87/32; } protocol tcp; destination-port ssh; } then accept; } term WEB { from { destination-address { 161.202.136.77/32; 10.129.33.87/32; } protocol tcp; port 8443; } then accept; } term DNS { from { protocol udp; source-port 53; } then accept; } } } routing-options { static { route 166.9.0.0/16 next-hop 10.129.33.65; route 0.0.0.0/0 next-hop 161.202.136.73; route 161.26.0.0/16 next-hop 10.129.33.65; route 10.0.0.0/8 next-hop 10.129.33.65; } }
インターフェイスセクションの変換
上記の 1G Public+Private スタンドアロンの例では、現在のアーキテクチャでは、集約されたインターフェイス ae0 と ae1 が追加されています。これらは、従来のアーキテクチャが ge-0/0/0(private/ae0)と ge-0/0/1(public/ae1)と定義するものにマッピングする必要があります。さらに、新しいアーキテクチャでは ge-0/0/2 と ge-0/0/3 が追加され、vSRX 仮想ファイアウォール インターフェイス内の冗長性をサポートします。従来のアーキテクチャでは、ホスト(ハイパーバイザー)の結合インターフェース(bond0 private/bond1 public)に冗長性が存在していた。現在のアーキテクチャでは、冗長性のためにgeインターフェイスに直接マッピングされたSR-IOV VFが使用されています。
vSRX スタンドアロン インターフェイス(現在のアーキテクチャ)と vSRX スタンドアロン インターフェイス(レガシー アーキテクチャ)におけるこれらの vSRX 仮想ファイアウォール構成の違いを比較できます。
ge-0/0/0 用に事前に設定されたプライベート VLAN は、ae0 経由でルーティングする必要があります。さらに、ge-0/0/1用に設定したパブリックVLANはすべて、ae1を介してルーティングする必要があります。
[ゾーン] セクションの変換
以前 ge-0/0/0 と ge-0/0/1 を参照していたデフォルト セキュリティ ゾーンでは、ae0.0(SL-PRIVATE)および ae1.0(SL-PUBLIC)インターフェイスを使用するようになりました。ge-0/0/0 および ge-0/0/1 と以前に参照されていたゾーンにも、同じ変更が適用されます。
その他の変更点
集約されたデバイス構成には、現在のアーキテクチャに以下の追加が必要です。
set chassis aggregated-devices ethernet device-count 10
JWEB設定には、集約されたインターフェイスも含まれます。
set system services web-management https interface ae1.0
set system services web-management https interface ae0.0
1G vSRX 仮想ファイアウォールの高可用性構成の移行
高可用性の設定では、従来のアーキテクチャから現在のアーキテクチャに設定をインポートする場合、主なvSRX仮想ファイアウォールが変更され、インターフェイスマッピングのわずかな変更になります。
現在のアーキテクチャの 1G SR-IOV HA 構成では、ホスト(ハイパーバイザー)の結合インターフェイスを使用する代わりに、冗長性のために vSRX 仮想ファイアウォール インターフェイスを追加できます。ホストがvSRX仮想ファイアウォールインターフェイスに直接マッピングできるSR-IOV VFを使用することで、これが可能になります。レガシー アーキテクチャからエクスポートされた構成は、現在のアーキテクチャにインポートする場合、これを考慮する必要があります。
1G HA の現在のアーキテクチャ向け vSRX 仮想ファイアウォールの構成については、 vSRX 高可用性インターフェイス(現在のアーキテクチャ) と、1G HA 用のレガシー アーキテクチャの vSRX 仮想ファイアウォールの構成を参照してください。 vSRX 高可用性インターフェイス(レガシー アーキテクチャ)を参照してください。
ge-0/* および ge-7/* インターフェイスが追加され、従来のアーキテクチャと現在のアーキテクチャの両方に存在する既存の reth インターフェイスに関連付けされました。これにより、vSRX仮想ファイアウォール設定内の冗長性が確保されます。fabインターフェイスに対しても冗長性が設定されています。