今回は、Viptelaと他製品間で連携する際に使用するService Chainingと呼ばれる機能について説明します。
概要
Service Chaining
例えば、SD-WANを導入した複数の拠点にFWを配置する場合、拠点数が増加するに伴い、FWの台数も増加します。
その結果、設備投資であるCAPEX(Capital Expenditure)や、運用コストであるOPEX(Operating Expense)が増加してしまいます。
Service Chainingを使用することで、上記の問題を解消することが可能です。
Service Chainingは、FWやLBなど他のサービスをViptelaに組み込むことができる機能で、特定の拠点間のトラフィックを組み込んだサービスに容易にリダイレクトできます。
この結果、FWやLBなどの台数を大幅に削減しつつ、必要なトラフィックに対してFWやLBなどのサービスを適用できます。
Service Chainingは前回の記事で説明したLabelを使用してトラフィックのリダイレクトを実現します。
VPNと同様に、vEdgeでサービスを作成すると、サービスに対してLabelが生成されます。
vEdgeがサービスへのリダイレクト対象のトラフィックを受信した際、リダイレクト先のサービスのLabelをパケットに割り当て、そのサービスが存在する拠点のvEdgeに対してパケットを転送します。
サービスが存在する拠点のvEdgeは、受信したパケットのLabelがサービスに割り当てたLabelと等しい場合、送信先IPアドレスを基にパケットをルーティングせずに、サービスのアドレスを基にパケットをルーティングします。
このようなメカニズムで、Service Chainingで組み込んだサービスに対して、トラフィックをリダイレクトします。
検証環境、内容
検証内容
vEdge1でServiceとしてFWを定義し、ASA1を指定します。
Service Chainingにより、Site 2とSite 3間の通信をSite 1のASA1にリダイレクトさせます。
物理/論理構成
オーバレイネットワーク構成
初期設定
system
system-ip 10.1.10.11
site-id 10
organization-name "Criterio1 - 19101"
vbond 172.16.10.21
!
vpn 0
interface eth0
ip address 172.16.10.11/24
tunnel-interface
no shutdown
!
ip route 0.0.0.0/0 172.16.10.254
system
host-name vBond
system-ip 10.1.10.21
site-id 10
organization-name "Criterio1 - 19101"
vbond 172.16.10.21 local vbond-only
!
vpn 0
interface ge0/0
ip address 172.16.10.21/24
tunnel-interface
encapsulation ipsec
!
no shutdown
!
ip route 0.0.0.0/0 172.16.10.254
system
host-name vSmart
system-ip 10.1.10.31
site-id 10
organization-name "Criterio1 - 19101"
vbond 172.16.10.21
!
vpn 0
interface eth0
ip address 172.16.10.31/24
tunnel-interface
no shutdown
!
ip route 0.0.0.0/0 172.16.10.254
system
host-name vEdge1
system-ip 1.1.1.1
site-id 1
organization-name "Criterio1 - 19101"
vbond 172.16.10.21
!
vpn 0
service FW address 10.1.1.100
interface ge0/0
ip address 172.16.1.1/24
tunnel-interface
encapsulation gre
color biz-internet restrict
!
no shutdown
!
ip route 0.0.0.0/0 172.16.1.254
!
vpn 10
interface ge0/1
ip address 10.1.1.1/24
no shutdown
system
host-name vEdge2
system-ip 2.2.2.2
site-id 2
organization-name "Criterio1 - 19101"
vbond 172.16.10.21
!
vpn 0
interface ge0/0
ip address 172.16.2.2/24
tunnel-interface
encapsulation gre
color biz-internet restrict
!
no shutdown
!
ip route 0.0.0.0/0 172.16.2.254
!
vpn 10
interface ge0/1
ip address 20.1.1.2/24
no shutdown
!
policy
app-visibility
system
host-name vEdge3
system-ip 3.3.3.3
site-id 3
organization-name "Criterio1 - 19101"
vbond 172.16.10.21
!
vpn 0
interface ge0/0
ip address 172.16.3.3/24
tunnel-interface
encapsulation gre
color biz-internet restrict
!
no shutdown
!
ip route 0.0.0.0/0 172.16.3.254
!
vpn 10
interface ge0/1
ip address 30.1.1.3/24
no shutdown
interface GigabitEthernet0/0
nameif inside
security-level 100
ip address 10.1.1.100 255.255.255.0
!
same-security-traffic permit intra-interface
!
route inside 0.0.0.0 0.0.0.0 10.1.1.1 1
interface GigabitEthernet2
ip address 20.1.1.12 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 20.1.1.2
aaa new-model
!
aaa authentication login default none
aaa authentication enable default none
!
interface GigabitEthernet2
ip address 30.1.1.13 255.255.255.0
!
ip route 0.0.0.0 0.0.0.0 30.1.1.3
!
line vty 0 4
privilege level 15
transport input telnet
◇R4の設定
interface GigabitEthernet2
ip address 172.16.1.254 255.255.255.0
!
interface GigabitEthernet3
ip address 172.16.2.254 255.255.255.0
!
interface GigabitEthernet4
ip address 172.16.3.254 255.255.255.0
!
interface GigabitEthernet5
ip address 172.16.10.254 255.255.255.0
設定、状態確認
Service Chaining設定前の疎通確認
R2からR3に対して、Telnetを実施します。
vEdge2でshow app dpi flows detailsコマンドを実行します。
現在はService Chainingの設定前なので、vEdge2はTelnetのパケットを、vEdge3に直接転送していることが確認できます。
vEdge2# show app dpi flows detail
app dpi flows vpn 10 20.1.1.12 30.1.1.13 19969 23 tcp
application telnet
family Terminal
active-since 2020-04-26T22:37:43+00:00
packets 352
octets 14745
tunnels-out 1
local-tloc ip 2.2.2.2
local-tloc color biz-internet
local-tloc encap gre
remote-tloc TLOC IP 3.3.3.3
remote-tloc color biz-internet
remote-tloc encap gre
packets 177
octets 7530
start-time 2020-04-26T22:37:43+00:00
vEdge1の設定確認
vEdge1では、service <サービスのタイプ> address <サービスのアドレス>コマンドにより、サービスを定義するのみです。
vpn 10
service FW address 10.1.1.100
サービスを定義すると、サービスに対して、自動的にLabelが割り当てられます。
vEdge1# show omp services
C -> chosen
I -> installed
Red -> redistributed
Rej -> rejected
L -> looped
R -> resolved
S -> stale
Ext -> extranet
Stg -> staged
Inv -> invalid
ADDRESS PATH
FAMILY VPN SERVICE ORIGINATOR FROM PEER ID LABEL STATUS
--------------------------------------------------------------------------------
ipv4 10 VPN 1.1.1.1 0.0.0.0 68 1003 C,Red,R
10 FW 1.1.1.1 0.0.0.0 68 1006 C,Red,R
VPN Listの確認
VPN Listで、Traffic Data Policyの適用先のVPNのIDを指定します。
Site Listの確認
Site Listで、Traffic Data Policyの適用先のSiteのIDを指定します。
Traffic Data Policyの確認
サービスをリダイレクトするためのアクションはServiceになります。
リダイレクト先のサービスのタイプ、リダイレクト先のサービスが存在するVPNとvEdgeのTLOCを指定します。
Default ActionにはAcceptを設定します。
Centralized Control Policyの確認
Traffic Rules > Traffic DataからCentralized Control PolicyにService Chaining用のTraffic Data Policyをインポートしておきます。
Policy Application > Traffic DataからインポートしたTraffic Data Policyの適用先のSiteとVPNを指定します。
vSmartのCentralized Control Policyの設定確認
vSmartでshow runコマンドを実行し、Centralized Control Policy用のコマンドを確認します。
vSmart# show run
.
<一部省略>
.
policy
data-policy _VPN_10_Traffic_Data_Policy
vpn-list VPN_10
sequence 1
match
source-ip 0.0.0.0/0
!
action accept
set
service FW vpn 10
service tloc 1.1.1.1 color biz-internet encap gre
!
!
!
default-action accept
!
!
lists
vpn-list VPN_10
vpn 10
!
site-list Site_2
site-id 2
!
site-list Site_3
site-id 3
!
!
!
apply-policy
site-list Site_2
data-policy _VPN_10_Traffic_Data_Policy from-service
!
site-list Site_3
data-policy _VPN_10_Traffic_Data_Policy from-service
vEdgeのCentralized Control Policyの情報確認
vEdge2でshow policy from-vsmartコマンドを実行し、Centralized Control Policyの情報を確認します。
vEdge2# show policy from-vsmart
from-vsmart data-policy _VPN_10_Traffic_Data_Policy
direction from-service
vpn-list VPN_10
sequence 1
match
source-ip 0.0.0.0/0
action accept
set
service FW
service vpn 10
service tloc 1.1.1.1
service tloc color biz-internet
service tloc encap gre
default-action accept
from-vsmart lists vpn-list VPN_10
vpn 10
Service Chaining設定後の疎通確認
R2からSV3に対して、Telnetを実施します。
R2#telnet 30.1.1.13 /source-interface GigabitEthernet2
Trying 30.1.1.13 ... Open
R3#
vEdge2でshow app dpi flows detailsコマンドを実行します。
現在はService Chainingの設定後なので、vEdge2はTelnetのパケットを、vEdge1に転送していることが確認できます。
vEdge2# show app dpi flows detail
app dpi flows vpn 10 20.1.1.12 30.1.1.13 30209 23 tcp
application telnet
family Terminal
active-since 2020-04-26T22:29:21+00:00
packets 226
octets 9495
tunnels-out 1
local-tloc ip 2.2.2.2
local-tloc color biz-internet
local-tloc encap gre
remote-tloc TLOC IP 1.1.1.1
remote-tloc color biz-internet
remote-tloc encap gre
packets 105
octets 4515
start-time 2020-04-26T22:29:21+00:00
以下は、vEdge2がオーバレイに転送したTelnetパケットのキャプチャになります。
送信先アドレスがvEdge1の172.16.1.1、ShimヘッダのLabelがvEdge1のServiceに割り当てられた1006であることが確認できます。
ASA1でshow conn longコマンドを実行すると、R2からR3へのTelnetのトラフィックがASA1を経由していることが確認できます。
ASA1# show conn long
TCP inside: 30.1.1.13/23 (30.1.1.13/23) inside: 20.1.1.12/30209 (20.1.1.12/30209), flags UIOB , idle 45s, uptime 4m48s, timeout 1h0m, bytes 486
コメント