AzureのVNETとAWSをVyOSでつなぐ

なんとなくお蔵入りしてたネタを引っ張りだしてきました。

AzureのVNETと動的ゲートウェイと、AWS上のVyOSなVPNルーターを使ってVPN接続しようというネタです。出来上がる環境はこんな感じ。

image

IPアドレスとかは例です。あと数か月以上前のネタなのでちょっと変わってる箇所あるかも(VyOSのAMIのバージョンとか)しれませんが適宜読み替えてください。それから簡易な接続なので本運用とかには使わない方がいいかもですね。なんにせよ自己責任で。

続きを読む

Azure Virtual Network Gatewayの改善

元ネタ:Azure Virtual Network Gateway Improvements

TechEd Europe 2014で仮想ネットワークゲートウェイの改善が発表されました。

  • ハイパフォーマンスなゲートウェイSKU
  • 仮想ネットワークゲートウェイに関する操作ログの保存
  • PFS(Perfect Forward Secrecy:前方秘匿性/将来に向けての機密保護)のサポート
  • 暗号化しないS2Sトンネルのサポート

ハイパフォーマンスなゲートウェイSKU

これまでのゲートウェイとの違いは以下の表のような感じです(これまでがDefault)

SKU ExpressRouteスループット S2S VPNスループット S2S最大トンネル数
Default ~ 500 Mbps ~ 80 Mbps 10
High Performance ~ 1000 Mbps ~ 200 Mbps 30

ちなみにお値段も少し違います。(1時間あたり0.49ドル) データ転送料などは同じ。

制限としては静的ルーティングゲートウェイは未サポートで、動的ルーティングゲートウェイとExpressRouteのときだけ使えます。

新規に作ることもできるし、既存のゲートウェイを変更することも可能です。

作り方

新規の時はNew-AzureVNetGatewayコマンドレット(Azure PowerShell)等で –GatewaySKU に指定するだけです。

New-AzureVNetGateway -VNetName MyAzureVNet -GatewayType DynamicRouting -GatewaySKU HighPerformance

HighPerformance か Default を指定します。

既存の変更方法

Resize-AzureVNetGateway コマンドレットで変更します。

Resize-AzureVNetGateway -VNetName MyAzureVNet -GatewaySKU HighPerformance

操作ログ

ゲートウェイの作成や削除、ExpressRouteのサーキット作成・削除・サーキットリンクの認証や作成・削除・BGPセッションの作成・削除・アップデートなどが管理ポータルの操作ログに出力されます。

PFSサポート

PFSはややこしいけど秘密鍵と公開鍵などが漏れてもセッションの機密は保たれる(セッションキーを別で生成するので安全)みたいな鍵交換の方式です。

で、この方式をサポートするので対応する機器であればより安全なセッションを張ることができるでしょうたぶん。

※IPSec(と他一部プロトコル)ぐらいしかサポートしてないので、S2S (VNET to VNET)のみサポートです

暗号化なしS2Sトンネルのサポート

S2Sの接続をする際に、暗号化せずに接続することができるようになりました。一般的にAzure上のVNET同士を接続する場合は比較的安全(盗聴される可能性が一般的なインターネット経由よりかなり低いという意味)なので、パケットの暗号化をしないことでスループットを上げることが可能です。

※On-Premiseとの接続などの場合はやめましょう

Azure 仮想ネットワークでのアドレス空間制限の緩和

17日にアナウンスがありましたが、Azureの仮想ネットワークで設定できるアドレス空間がRFC1918に記載されているプライベート空間以外も指定できるようになりました。

ようは以下の3つのアドレス空間内でやりくりしてねってのが今までです。

  • 10.0.0.0    –    10.255.255.255 (10/8 prefix)
  • 172.16.0.0    –    172.31.255.255 (172.16/12 prefix)
  • 192.168.0.0    –    192.168.255.255 (192.168/16 prefix)

今後は関係なく設定できるようになったので、より柔軟にネットワークが構成できるかもですね。(IPアドレスは正しく使いましょう)

image

Azure のネットワークACLの挙動

こういうお話がありました。

結論からいうと、LBとかじゃなくてホストサーバー上の設定なのでVNET(特に拒否の設定)指定ができちゃいます。

とはいえちょっと気になったので見てみることにします。こんなVNET to VNETなネットワークをAzure上で組んでみました。

image

ca1-srv1-vnet1 なインスタンスにIISを入れてHTTP(tcp/80)なエンドポイントを定義します。(LBは省略しました)

ネットワークACL(エンドポイントACL)を何も設定しない際に各インスタンスで内部のIPアドレスと外部のFQDN(図だとca1.cloudapp.net)にブラウザで接続してIISの既定のページが見れることは確認済みな状態とします。(Azure外のクライアントも当然OK)

※ようは疎通できてる状態

さて、以下の表のような感じでACLを定義したときに、それぞれのインスタンスから内部IPとFQDNでアクセスしてどうなるかを見てみました。

ACLの状態 ca1-srv1-vnet1   ca1-srv2-vnet1   ca2-src1-vnet1   ca3-srv1-vnet2   外部PC
  内部IP FQDN 内部IP FQDN 内部IP FQDN 内部IP FQDN FQDN
vnet1のみ許可 OK OK OK OK OK NG OK NG NG
vnet1のみ拒否 OK OK NG OK NG OK OK OK OK
vnet2のみ許可 OK OK OK OK OK NG OK NG NG
vnet2のみ拒否 OK OK OK OK OK OK NG OK OK
外部PCのみ許可 OK OK OK OK OK NG OK NG OK
外部PCのみ拒否 OK OK OK OK OK OK OK OK NG
ca1のGIPのみ許可 OK OK OK OK OK NG OK NG NG
ca1のGIPのみ拒否 OK NG OK NG OK OK OK OK NG
ca2のGIPのみ許可 OK OK OK OK OK OK OK NG NG
ca2のGIPのみ拒否 OK OK OK OK OK NG OK OK OK
ca3のGIPのみ許可 OK OK OK OK OK NG OK OK NG
ca3のGIPのみ拒否 OK OK OK OK OK OK OK NG OK

 

※クラウドサービスのグローバルIPアドレスは一応インスタンス上からインターネットにアクセスした際に使用されるIPアドレスを確認して設定

本来ネットワークACLは許可だけが設定されたらそのルールにマッチしないものは拒否になるはずですが、VNETを許可した場合はその辺うまく動作してない様子。

例えばvnet1だけ許可した場合だと、vnet2にいるインスタンスからもアクセスできてしまっています。(期待値としては拒否してほしい)

ただ拒否設定の場合は想定どおりになるようなので、何とも不可思議な挙動です。(表中で怪しいところをわかりやすくしようと思ったけど、面倒くさくなったので放置)

但し、ネットワークACLのドキュメントを見る限りでは

仮想ネットワークに対して ACL を指定したり、仮想ネットワーク内にある特定のサブネットに対して ACL を指定したりすることはできません。

とあるので今のところこのあたりの挙動は想定外なのかもです。今後に期待。

また、ネットワークACLのパケットフィルタ処理はホストノード上で実行されるようです。

ACL を作成して仮想マシンのエンドポイントに適用するとき、パケット フィルターが VM のホスト ノードで実行されます。これは、リモート IP アドレスからのトラフィックのフィルター処理が、VM 上ではなく、ホスト ノードによって実行され、ACL ルールとの照合が行われることを意味します。これにより、パケット フィルターの処理で VM が重要な CPU サイクルを消費するのを防ぐことができます。

上位のFWとかルータじゃなかったのねー。

まぁとりあえず現状はVNETに対するACLは微妙にノンサポートという感じですので、もし制限したい場合はご注意ください。(意図せず外部はOKになったりする可能性があります)