前回の記事ではCentralized Control Policyを使用したローカルブレイクアウトについて説明しました。
今回は、Static Routeを使用したローカルブレイクアウトについて説明したいと思います。
概要
Centralized Control Policyを使用したローカルブレイクアウトのイメージ
Centralized Control Policyを使用したローカルブレイクアウトは、昔からCisco機器で実装されているPBR(Policy Base Routing)により、本来はオーバレイに転送されるトラフィックを、無理やり、アンダーレイのWANインタフェースから転送させるイメージになります。
Static Routeを使用したローカルブレイクアウトのイメージ
Static Routeを使用したローカルブレイクアウトは、自然なルーティングの処理によって、本来はオーバレイに転送されるトラフィックを、無理やり、アンダーレイのWANインタフェースから転送するイメージになります。
Static Routeを使用したローカルブレイクアウトの問題点は、アプリケーション単位でのローカルブレイクアウトはできません。
Office 365のトラフィックのみローカルブレイクアウトさせる、ようなことはできません。
検証環境、内容
検証内容
R2からSV1(172.16.1.100)に対して、Telnetを実施します。
そして、vEdge2において、172.16.1.100宛のパケットをローカルブレイクアウトさせます。
物理/論理構成
オーバレイネットワーク構成
初期設定
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
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
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
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
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
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
設定、動作確認
Static Route設定前の状態、疎通確認
R2からSV1に対して、Telnetを実施します。
最初にvEdge2のService VPNのルーティングテーブルを確認します。
vEdge2# show ip routes vpn 10 | tab
ADDRESS PATH PROTOCOL NEXTHOP NEXTHOP NEXTHOP
VPN FAMILY PREFIX ID PROTOCOL SUB TYPE METRIC IFNAME ADDR TLOC IP COLOR ENCAP VPN STATUS
-------------------------------------------------------------------------------------------------------------------------------
10 ipv4 0.0.0.0/0 0 omp - 0 - - 1.1.1.1 biz-internet ipsec - F,S
10 ipv4 10.1.1.0/24 0 omp - 0 - - 1.1.1.1 biz-internet ipsec - F,S
10 ipv4 20.1.1.0/24 0 connected - 0 ge0/1 - - - - - F,S
ロンゲストマッチにより、vEdge2はSV1の172.16.1.100宛のパケットを、オーバレイ経由でvEdge1に転送します。
vEdge2でshow app dpi flows detailsコマンドを実行します。
現在はローカルブレイクアウト用のスタティックルートの設定前なので、vEdge2はTelnetのパケットを、オーバレイ経由でvEdge1に転送していることが確認できます。
vEdge2# show app dpi flows detail
app dpi flows vpn 10 20.1.1.12 172.16.1.100 20993 23 tcp
application telnet
family Terminal
active-since 2020-04-05T13:54:40+00:00
packets 65
octets 2927
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 35
octets 1492
start-time 2020-04-05T13:54:40+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 30
octets 1435
start-time 2020-04-05T13:54:40+00:00
R1はLANからWANにパケットを転送する送信元アドレスをNATで変更します。
そのため、SV1のTelnetのアクセスログを見ると、R1のWANインタフェースのアドレスが確認できます。
[root@localhost ~]# cat /var/log/messages | grep Telnet
Apr 5 14:44:35 localhost systemd: Started Telnet Server (172.16.1.11:5062).
Apr 5 14:44:35 localhost systemd: Starting Telnet Server (172.16.1.11:5062)...
vEdge2にローカルブレイクアウト用の設定を追加
SV1の172.16.1.100宛のパケットをアンダーレイへ転送するために、スタティックルートを設定します。
ip routeコマンドの<address>/<prefix-length>でローカルブレイクアウト対象のアドレスを指定します。
また、このスタティックルートにマッチしたパケットをアンダーレイであるTransport VPNに転送するために、ネクストホップにvpn 0を指定します。
Centralized Control Policyを使用したローカルブレイクアウトの時と同様に、ローカルブレイクアウトの際、パケットの送信元アドレスをvEdgeのWANインタフェースのアドレスに変換するためにvEdge2のge0/0にnatコマンドを設定します。
vpn 0
interface ge0/0
nat
!
!
vpn 10
ip route 172.16.1.100/32 vpn 0
Static Route設定後の状態、疎通確認
R2からSV1に対して、Telnetを実施します。
最初にvEdge2のService VPNのルーティングテーブルを確認します。
vEdge2# show ip routes vpn 10 | tab
ADDRESS PATH PROTOCOL NEXTHOP NEXTHOP NEXTHOP
VPN FAMILY PREFIX ID PROTOCOL SUB TYPE METRIC IFNAME ADDR TLOC IP COLOR ENCAP VPN STATUS
-----------------------------------------------------------------------------------------------------------------------------------
10 ipv4 0.0.0.0/0 0 omp - 0 - - 1.1.1.1 biz-internet ipsec - F,S
10 ipv4 10.1.1.0/24 0 omp - 0 - - 1.1.1.1 biz-internet ipsec - F,S
10 ipv4 20.1.1.0/24 0 connected - 0 ge0/1 - - - - - F,S
10 ipv4 172.16.1.100/32 0 nat - 0 ge0/0 - - - - 0 F,S
ロンゲストマッチにより、vEdge2はSV1の172.16.1.100宛のパケットを、Transport VPNに所属するge0/0から転送します。
vEdge2のshow app dpi flows detailsコマンドの出力にTLOCの情報が含まれていないため、vEdge2はTelnetのパケットを、オーバレイ経由でvEdge1に転送せずに、アンダーレイのWANインタフェースから転送していることが確認できます。
vEdge2# show app dpi flows detail
app dpi flows vpn 10 20.1.1.12 172.16.1.100 26625 23 tcp
application telnet
family Terminal
active-since 2020-04-05T14:06:27+00:00
packets 62
octets 2810
vEdge2でshow ip nat filterコマンドの出力から、Telnetパケットの送信元アドレスがvEdge2のWANインタフェースのアドレスに変換されていることが確認できます。
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 26625 23 172.16.2.2 172.16.1.100 26625 23 established 0:00:58:27 34 2069 28 1857 -
SV1のTelnetのアクセスログを見ると、vEdge2のWANインタフェースのアドレスが確認できます。
[root@localhost ~]# cat /var/log/messages | grep Telnet
Apr 5 13:39:17 localhost systemd: Started Telnet Server (172.16.2.2:26625).
Apr 5 13:39:17 localhost systemd: Starting Telnet Server (172.16.2.2:26625)...
上記の様に、スタティックルートを1個設定するだけで、簡単にローカルブレイクアウトを実現することが可能です。
補足
ローカルブレイクアウト用のスタティックルートを設定した際にルーティングテーブルに投入されたルート情報の生成元のプロトコルはnatになります。
vpn 10
ip route 172.16.1.100/32 vpn 0
vEdge2# show ip routes vpn 10 172.16.1.100/32 | tab
ADDRESS PATH PROTOCOL NEXTHOP NEXTHOP NEXTHOP
VPN FAMILY PREFIX ID PROTOCOL SUB TYPE METRIC IFNAME ADDR TLOC IP COLOR ENCAP VPN STATUS
-----------------------------------------------------------------------------------------------------------------------------------
10 ipv4 172.16.1.100/32 0 nat - 0 ge0/0 - - - - 0 F,S
このルート情報をOSPFやBGPで再配送するにredistribute staticコマンドではなく、redistribute natコマンドが必要になります。
vpn 10
router
ospf
redistribute nat
vpn 10
router
bgp 1
address-family ipv4-unicast
redistribute nat
コメント