第20回 NATの技術③ VRF×NAT構成検証

これまで[スタティックNAT](https://qiita.com/infra-blog/items/0930f6809d031848c1c5)と[ダイナミックNAT](https://qiita.com/infra-blog/items/2f9789ac5dcbd8349f43)など、NAT関連の記事を書いてきました。
NATの最終回である今回は、少しマイナーなNATの技術を書こうと思います。

## VASIを使用したVRF間のNAT

以前[こちらの記事](https://qiita.com/infra-blog/items/a713bd9f3b8591cfbd1d)で、一つのルーターにおいて複数のルーティングテーブルを運用するVRFを記載しました。
ルーティングテーブルを分けることで、ルーターをシェアできるのは良いことですが、支店が統合などをした際、それぞれのルーティングテーブルごとに設定を入れるのは時間もかかり、設定が多くなり複雑になってくるほど作業ミスも発生しやすくなるリスクも含んでおります。
そういう時、VRF間同士の通信を実現する技術が**VASI**になります。
このVASIを使用することで**NATなどの通信もVRF間をまたいで実現ができます。**

## VASI（VRF-Aware Software インフラストラクチャ）
これは**vasirightとvasileftの2つのペアで構成**され、Ciscoのルーターにおいて異なるVRF間、またはVRFと非VRF間において**vasirightとvasileftのインターフェースで仮想リンクを作成し、ここを経由した通信を実現する**技術です。

### 検証構成
![⑦.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559536/cc2e7c27-8ab8-4c09-8b2d-bdc2ad135d00.png)


#### VASIを使用しない場合

宛先の172.16.1.1に到達せず、pingが成立しない。
![⑤.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559536/4007b922-3363-4259-8c36-b0f23ac57473.png)

#### vasirightとvasileftのペアを成立させることで以下のようにpingが通る。
![⑥.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559536/2c7d74d7-4e5d-451b-aaef-c2f5370a01ee.png)

今回は2パターンの環境を構築し検証を行いました。

## 環境① VRF_TEST01⇔VRF_TEST02間のNAT通信
![①.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559536/401c421d-b980-4384-8538-9efa6385eb0c.png)


```ruby:##ルーター設定
vrf definition VRF_TEST01
 rd 1:1
 !
 address-family ipv4
 exit-address-family
!
vrf definition VRF_TEST02
 rd 2:2
 !
 address-family ipv4
 exit-address-family
!
interface GigabitEthernet1
 vrf forwarding VRF_TEST01
 ip address 192.168.1.2 255.255.255.0
no shut
!
interface GigabitEthernet2
 vrf forwarding VRF_TEST02
 ip address 172.16.1.2 255.255.255.0
 ip nat outside
no shut
!
interface vasileft8
 vrf forwarding VRF_TEST01
 ip address 10.1.1.1 255.255.255.248
 no keepalive
!
interface vasiright8
 vrf forwarding VRF_TEST02
 ip address 10.1.1.4 255.255.255.248
 ip nat inside
 no keepalive
!
ip nat inside source static 192.168.1.1 172.16.1.5 vrf VRF_TEST02
ip route vrf VRF_TEST01 172.16.0.0 255.255.0.0 vasileft8
ip route vrf VRF_TEST02 192.168.0.0 255.255.0.0 vasiright8
!

```
### 検証結果
![③.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559536/e323ce8c-d27e-441b-a950-a200e9f6ddc0.png)

送信元アドレスが**192.168.1.1→172.16.1.5**へNAT変換が行われ通信成功。

## 環境③ VRF_TEST01⇔非VRF間のNAT通信
片方がVRFで、**もう片方は非VRFの環境**でも通信が実現するかの検証
![②.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559536/54cf9f3e-aad9-4630-aba7-383fce3ed0bb.png)

```ruby:##ルーター設定
vrf definition VRF_TEST01
 rd 1:1
 !
 address-family ipv4
 exit-address-family
!
interface GigabitEthernet1
 vrf forwarding VRF_TEST01
 ip address 192.168.1.2 255.255.255.0
no shut
!
interface GigabitEthernet2
 ip address 172.16.1.2 255.255.255.0
 ip nat outside
no shut
!
interface vasileft18
 vrf forwarding VRF_TEST01
 ip address 10.1.1.1 255.255.255.248
 no keepalive
!
interface vasiright18
 ip address 10.1.1.4 255.255.255.248
 ip nat inside
 no keepalive
!
ip nat inside source static 192.168.1.1 172.16.1.99
ip route 192.168.0.0 255.255.0.0 vasiright18
ip route vrf VRF_TEST01 172.16.0.0 255.255.0.0 vasileft18
!
```

### 検証結果
![④.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/559536/66372431-921c-4052-90e5-ced07dc37f14.png)

送信元アドレスが**192.168.1.1→172.16.1.99**へNAT変換が行われ通信成功。

## 参考
https://www.cisco.com/c/ja_jp/support/docs/ip/network-address-translation-nat/200255-Configure-VRF-Aware-Software-Infrastruct.html

https://www.lab-infra.com/vrf/cisco-vrf-vasi

## 次回予告
これまでネットワークが続いたので、久しぶりに次回は現場での改善を記載します。
内容は**Copilotを使用した業務改善**について