従来の設定から現在の 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 10JWEB設定には、集約されたインターフェイスも含まれます。
set system services web-management https interface ae1.0set 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インターフェイスに対しても冗長性が設定されています。