Viptela ローカルブレイクアウト(Centralized Control Policyを使用)

今回は、SD-WANの主要な機能であるローカルブレイクアウトについて説明します。
Viptelaのローカルブレイクアウトの実装方法は2種類ありますが、今回はCentralized Control Policyを使用してローカルブレイクアウトを実現します。

この記事の目次

概要
1. ローカルブレイクアウト
2. Viptelaのローカルブレイクアウトで実現不可能なこと
検証環境、内容
設定、動作確認

概要

ローカルブレイクアウト

SD-WANを導入する前は、ブランチ拠点の端末のインターネット宛のトラフィックは、IPsec VPN等を経由して、一度、ハブ拠点に転送されます。
その後、ハブ拠点のゲートウェイ経由で、インターネットに出ていく設計が多いです。

上記の様な設計の場合、Office 365等の大量のトラフィックがハブ拠点に転送され、輻輳や遅延等が発生してしまいます。

この様な問題を解決するために、SD-WANではローカルブレイクアウトと呼ばれる機能を導入しました。
ローカルブレイクアウトを使用することで、ブランチ拠点のWAN回線から、特定のアプリケーションのトラフィックを直接インターネットに転送できます。

大容量のトラフィックが発生するアプリケーションをローカルブレイクアウトすることで、輻輳や遅延等を解消できます。

Viptelaでは、ローカルブレイクアウトのことを、DIA(Direct Internet Access)と呼んだりします。

Viptelaのローカルブレイクアウトで実現不可能なこと

Viptelaでは、ハブ拠点のvEdgeがオーバレイから受信したパケットを、直接、自身のWANインタフェースからローカルブレイクアウトさせることはできません。。。
ちなみに、VelocloudやSilverPeakではこの動作は可能です。

検証環境、内容

検証内容

R2からSV1に対して、Telnetを実施します。
そして、vEdge2において、Telnetのパケットをローカルブレイクアウトさせます。
(インターネットに出れない閉じた環境で検証しているので、アプリケーションではなく、従来のIPアドレスやポート番号を条件に使用します。。。)

物理/論理構成

オーバレイネットワーク構成

初期設定

vManageの設定


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

vBondの設定


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

vSmartの設定


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

vEdge1の設定


system
 host-name               vEdge1
 system-ip               1.1.1.1
 site-id                 1
 organization-name       "Criterio1 - 19101"
 vbond 172.16.10.21
!
vpn 0
 interface ge0/0
  ip address 172.16.1.1/24
  tunnel-interface
   encapsulation ipsec
   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
 !
 ip route 0.0.0.0/0 10.1.1.11

vEdge2の設定


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
  nat
  tunnel-interface
   encapsulation ipsec
   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

R1の設定


interface GigabitEthernet2
 ip address 10.1.1.11 255.255.255.0
 ip nat inside
!
interface GigabitEthernet3
 ip address 172.16.1.11 255.255.255.0
 ip nat outside
!
ip nat inside source list 1 interface GigabitEthernet3 overload
ip route 0.0.0.0 0.0.0.0 172.16.1.254
ip route 20.1.1.0 255.255.255.0 10.1.1.1
!
access-list 1 permit any

R2の設定


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

R3の設定


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.10.254 255.255.255.0

設定、動作確認

Centralized Control Policy適用前の疎通確認

R2からSV1に対して、Telnetを実施します。

vEdge2でshow app dpi flows detailsコマンドを実行します。
現在はローカルブレイクアウト設定前なので、vEdge2はTelnetのパケットを、オーバレイ経由でvEdge1に転送していることが確認できます。

vEdge2


vEdge2# show app dpi flows detail
app dpi flows vpn 10 20.1.1.12 172.16.1.100 20481 23 tcp
 application  telnet
 family       Terminal
 active-since 2020-04-05T12:41:05+00:00
 packets      65
 octets       2930
 tunnels-in 1
  local-tloc TLOC IP 2.2.2.2
  local-tloc color biz-internet
  local-tloc encap ipsec
  remote-tloc TLOC IP 1.1.1.1
  remote-tloc color biz-internet
  remote-tloc encap ipsec
  packets    36
  octets     1532
  start-time 2020-04-05T12:41:05+00:00
 tunnels-out 1
  local-tloc ip 2.2.2.2
  local-tloc color biz-internet
  local-tloc encap ipsec
  remote-tloc TLOC IP 1.1.1.1
  remote-tloc color biz-internet
  remote-tloc encap ipsec
  packets    29
  octets     1398
  start-time 2020-04-05T12:41:05+00:00

R1はLANからWANにパケットを転送する送信元アドレスをNATで変更します。
そのため、SV1のTelnetのアクセスログを見ると、R1のWANインタフェースのアドレスが確認できます。

SV1


[root@localhost ~]# cat /var/log/messages | grep Telnet
Apr  5 13:30:58 localhost systemd: Started Telnet Server (172.16.1.11:5063).
Apr  5 13:30:58 localhost systemd: Starting Telnet Server (172.16.1.11:5063)...

vEdge2の設定の確認

ローカルブレイクアウトの際、パケットの送信元アドレスをvEdgeのWANインタフェースのアドレスに変換する必要があるため、vEdge2のge0/0にnatコマンドを設定します。
また、動作確認のためにapp-visibilityコマンドを設定します。

vEdge2


vpn 0
 interface ge0/0
  nat
 !
!
policy
 app-visibility

VPN Listの確認

VPN Listで、Traffic Data Policyの適用先のVPNのIDを指定します。

Site Listの確認

Site Listで、Traffic Data Policyの適用先のSiteのIDを指定します。

Traffic Data Policyの確認

ローカルブレイクアウト用のアクションはNAT VPNになります。(分かり難い。。。)
Service VPNのパケットを、Transport VPN(ID = 0)に強制的に転送するイメージになります。

他の通信はハブ拠点に転送させるために、Default ActionにはAcceptを設定します。

Centralized Control Policyの確認

Traffic Rules > Traffic DataからCentralized Control Policyにローカルブレイクアウト用のTraffic Data Policyをインポートしておきます。

Policy Application > Traffic DataからインポートしたTraffic Data Policyの適用先のSiteとVPNを指定します。

vSmartへのCentralized Control Policyの適用

vSmartにCentralized Control Policyを適用します。

適用方法が分からない場合は、こちらの記事を参照お願いします。

Centralized Control Policy適用後のvSmartの状態確認

vSmartでshow runコマンドを実行し、Centralized Control Policy用のコマンドを確認します。

vSmart


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
     destination-port 23
     protocol         6
    !
    action accept
     nat use-vpn 0
    !
   !
   default-action accept
  !
 !
 lists
  vpn-list VPN_10
   vpn 10
  !
  site-list Site_2
   site-id 2
  !
 !
!
apply-policy
 site-list Site_2
  data-policy _VPN_10_Traffic_Data_Policy from-service

Centralized Control Policy適用後のvEdgeの状態確認

vEdge2でshow policy from-vsmartコマンドを実行し、Centralized Control Policyの情報を確認します。

vEdge2


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
    destination-port 23
    protocol         6
   action accept
    nat use-vpn 0
    no nat fallback
  default-action accept
from-vsmart lists vpn-list VPN_10
 vpn 10

Centralized Control Policy適用後の疎通確認

R2からSV1に対して、Telnetを実施します。

vEdge2のshow app dpi flows detailsコマンドの出力にTLOCの情報が含まれていないため、vEdge2はTelnetのパケットを、オーバレイ経由でvEdge1に転送せずに、ローカルブレイクアウトしていることが確認できます。

vEdge2


vEdge2# show app dpi flows detail
app dpi flows vpn 10 20.1.1.12 172.16.1.100 11777 23 tcp
 application  telnet
 family       Terminal
 active-since 2020-04-05T12:49:24+00:00
 packets      65
 octets       2923

vEdge2でshow ip nat filterコマンドを実行することで、NATによりアドレス変換されたセッションが確認できます。

vEdge2


vEdge2# show ip nat filter

                            PRIVATE                   PRIVATE  PRIVATE  PUBLIC                    PUBLIC  PUBLIC
NAT  NAT                    SOURCE      PRIVATE DEST  SOURCE   DEST     SOURCE      PUBLIC DEST   SOURCE  DEST    FILTER       IDLE        OUTBOUND  OUTBOUND   INBOUND  INBOUND
VPN  IFNAME  VPN  PROTOCOL  ADDRESS     ADDRESS       PORT     PORT     ADDRESS     ADDRESS       PORT    PORT    STATE        TIMEOUT     PACKETS   OCTETS     PACKETS  OCTETS     DIRECTION
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
0    ge0/0   10   tcp       20.1.1.12   172.16.1.100  11777    23       172.16.2.2  172.16.1.100  11777   23      established  0:00:54:47  36        2189       29       1904       -

SV1のTelnetのアクセスログを見ると、vEdge2のWANインタフェースのアドレスが確認できます。

SV1


[root@localhost ~]# cat /var/log/messages | grep Telnet
Apr  5 13:39:17 localhost systemd: Started Telnet Server (172.16.2.2:11777).
Apr  5 13:39:17 localhost systemd: Starting Telnet Server (172.16.2.2:11777)...

補足ですが、cEdgeの方が、ローカルブレイクアウト時のフロー情報はより詳細に確認できます。

cEdge


cEdge#show sdwan app-fwd dpi flows detail
app-fwd cflowd flows-detail vpn 10 src-ip 10.1.1.11 dest-ip 20.190.141.229 src-port 50620 dest-port 443 dscp 0 ip-proto 6
 tcp-cntrl-bits    26
 icmp-opcode       0
 total-pkts        15
 total-bytes       1375
 start-time        "Wed Aug 21 06:45:29 2019"
 egress-intf-name  GigabitEthernet0/0/1
 ingress-intf-name GigabitEthernet0/1/1
 application       ms-office-365
 family            microsoft-office