0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Azure ネットワークルーティングのプラクティス②

Posted at

先日とあるコミュニティイベントで執り行いました資料なしホワイトボードに殴り書きと言うライトニングトークの内容をまとめてみました。
ネタは Azure ネットワークルーティングのプラクティス、都合3回でお送りいたします。

2. 仮想マシンに複数 NIC をアタッチした場合のルーティング

第 2 回は仮想マシンに複数 NIC をアタッチした場合のルーティングについてです。

同一サブネットに複数 NIC

まずは同一サブネットに複数 NIC をアタッチする構成です。
この構成を取る要件はあまりなく実際お目にかかることは少ないと思いますが、基本的な説明にはちょうど良いのでひとつ挟ませてください。
image.png
この構成で VM2 から VM1 に ping を打つと、NIC1 には通りますが NIC2 はタイムアウトします。
VM1 のルーティングテーブルを見てみますと、
image.png
とデフォルトルートは NIC1 (192.168.253.132) のみに付いており NIC2 にはサブネット外へのルートがありませんのでこのような動きになるわけですね。

異なるサブネットに複数 NIC

次に複数 NIC を使用する主な用途となる異なるサブネットにアタッチする構成です。
image.png
この構成では VM2 から VM1 の NIC1・NIC2 双方に ping が通ります。
同様に VM1 のルーティングテーブルを見てみますと、
image.png
と NIC1 (192.168.253.132) のデフォルトルートと合わせて NIC2 (192.168.253.14) に同一サブネットへのルートが付いていますので、結果 ping に応答できるようになっています。

異なるサブネットに複数 NIC + VPN

さらに複数 NIC に VPN を組み合わせた構成です。
image.png
この構成ではオンプレミス側の VM から NIC1 には ping が通り NIC2 には通らないと言う動作になります。
NIC2 にはサブネット外へのルートがありませんので VPN の先からの通信にも反応することができない形となります。

複数のパブリック IP

パブリック IP を絡めたパターンです、同一サブネットの複数 NIC にパブリック IP をつけてみましょう。
これは先日実際に取り扱った事例です。
image.png
この場合 NIC1 のパブリック IP には接続可能ですが NIC2 はタイムアウトが発生します。
VM1 のルーティングテーブルを見てみますと、
image.png
と同一サブネットに複数 NIC の際と全く同じ設定になっています。(検証環境につきインターフェース番号は変わってます)
でもおかしいですね、この構成であればパブリック IP を使用するルートがあって然るべきですが ↑ のルーティングテーブルにはありません。
ここで ipconfig も見てみますと、
image.png
となっており OS レイヤーではパブリック IP が付与されていないことが分かります。
つまり NIC のプライベート IP と パブリック IP の間にもデフォルトゲートウェイを介したルーティングが行われているらしく、冒頭の同一サブネットに複数 NIC と同じ挙動が発生している訳です。

複数 NIC のデフォルトルートの対処法

では対処法ですが、本記事の構成では共通して ↓ の記事にある 2 つめ以降の NIC に OS レイヤーでのルートを追加設定することが対処法となります。

例えばこのコマンドですね。

route add -p 0.0.0.0 MASK 0.0.0.0 192.168.2.1 METRIC 5015 IF 7

これにより 2 つめ以降の NIC のサブネット外へのルートが確立し VPN の先でもパブリック IP でも到達できるようになります。
ただ Azure のネットワーク構成に追随するのに OS レイヤーで手を入れるというのは、構成変更などへの対応を考慮するとリスクもあり激しく面倒ですよね…

補足

最後に複数 NIC を使うべきかと言う観点になりますが補足を 2点ほど。

NIC を増やしても帯域は増えない

↓ に記載の通り帯域幅は仮想マシンのサイズで決まっており NIC を増やしても帯域幅は増えません。
また Azure では NIC ごとの帯域幅制御機能は提供されておらず、OS より上のレイヤーでソフトウェア (BITS とか) による対応が必要となります。

あんまり推奨されてない

こんな注意喚起がされてます。
image.png

おわりに

実際には複数 NIC に起因するトラブルはあまりお見掛けしないと思います、今回はたまたま複数のパブリック IP 起因での事例が直近でありましたので振り返りと自己学習も兼ねて記事にしてみました。
複数 NIC は Azure から見えるルーティングと OS レイヤーのルーティングを一致させる作業が必須で、保守性が著しく悪くなりますので個人的にはあまりやりたくない構成の 1 つだと思います。
それでは第 3 回は「ロンゲストマッチの絡んだルーティング」の予定です。

本稿を読んでいただきありがとうございました!

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?