自宅とさくらのクラウドをVyOSとSoftEtherで繋いだ

「ネット無料!」というアパートに引っ越しました。ホテルの「インターネット接続」と同様の接続形態です。NAT(NAPT)配下に端末が置かれる構成です。

この端末にグローバル側からアクセスする場合、宛先NATを利用する必要がありますが、単なる住民にそんな権限は…当然ありません。さらに、インターネット上のサーバと平文で通信する際、他の住民や大家に通信を覗き見される可能性も、ゼロではありません。

そこで、アパートと「さくらのクラウド」をVPNで繋ぐ実験を行いました。これによって、心配事が解決した上で、さくらのクラウド経由でアパート内にアクセスすることができるようになりました。インターネットさえ繋がっていれば、どこからでもアクセスできます。

なお、この「さくらのクラウド」には、先日の「SECCON2015 intercollege」での優勝によって頂いたクーポンを一部利用しています。

構成

全体の構成図は、こんな感じです。
vpn
最低でもサーバ2台+スイッチ1台の、まともに料金を払っていたら破産しそうな構成です。実際は、さらにサーバが1台あるので、恐ろしいですね。

多少タイトルに偽りありですが、VyOSは「VPCルータ」相当です。VPCルータそのものを使っても良かったのですが、VyOSを使ってみたかったのです。また、SoftEtherとIX2015は、今回のVPN構築の要です。詳細は後述しますが、全体でL2「っぽい」接続性を確保しています。

なお、VPCルータについて後日検証した(クーポンはたっぷりあるので)ところ、「ヘアピンNATが利用できない」ことが分かりました。サポートに問い合わせた結果ではありませんが、少し面倒くさそうです。VPCルータは、内部的にはVyOSだそう(さくらのクラウドでVyOS使ってみた)ですが、コンソールにアクセスすることもできません。整合性やOS本体のバージョンアップを考えると当然ですが、そうなると static-host-mapping でどうにかするのは無理そうです。新たにDNSサーバを立てるか、各マシンの hosts を調整するか、でしょうか。もっとも、さくらのクラウドで、しかもVPCルータまで用意するような構成でヘアピンNATが必要になるってのもあまり無いとは思います。

SoftEther

当初、SoftEther VPN Serverがインストールされたサーバは、これらの構成を取るつもりでいました。
fail
しかし、構成1については、「複数NICを同一のスイッチに接続することはできない(よくある質問(技術的な事項) | 仮想サーバのNICをBonding構成にすることは可能ですか?)」ため不可能。さらに、構成2については、tapをLinuxブリッジへ繋ぐと上手く通信できず断念。また、構成3については、スイッチ側にパケットが流れていかないという事態になりました。

というのも、さくらのクラウドでは、スイッチを通過できるパケットに制限(よくある質問(技術的な事項) | スイッチやルータ+スイッチを通過できないパケットはありますか?)があり、「送信元MACアドレスがサーバに割り当てられたNICのものでないとダメ」とのことでした。SoftEtherは、L2-VPNを構築するため、これで引っかかったようです。

そこで、「VPCルータ」を作成した上でL2TP/IPsec接続を行い、スイッチに流れてくるパケットを観察してみました。すると、送信元MACアドレスのOUIが、「SAKURA INTERNET INC.」のものになっていました。VPCルータのMACアドレスを確かめる手段はありませんが、このアドレスがVPCルータのものでしょう。ということで、送信元MACアドレスを書き換えた上で通信していました。「VPCルータから出てきたパケットは、どんな送信元MACアドレスでもスイッチを通れるんじゃないの」と思っていましたが、例外はないようです。

そのため、このような処理を自前で行います。とはいえ、下記のような構成にした上で、Proxy ARPを有効にするだけです。
success
なお、単純に「eth1」をSoftEther側(の仮想HUB)に繋いだ場合、やはり上手くいきませんでした。この辺は、3.6 ローカルブリッジ - SoftEther VPN プロジェクト内「Linuxでローカルブリッジを使うときには~」といった話でしょう。

また、この際に設定するNICは、eth0とeth1に加え、「all」も必要だったことを記載しておきます。

net.ipv4.conf.eth0.proxy_arp=1
net.ipv4.conf.eth1.proxy_arp=1
net.ipv4.conf.all.proxy_arp=1

ただ、「br0」や「tap」も指定すれば同じことですし、eth0とeth1に「加え」としましたが、all を入れれば eth0 と eth1 は不要です。

これでProxy ARPの設定ができたわけですが、DHCPはどうにもなりません。そこで、SoftEtherの「SecureNAT」機能のうち、DHCPサーバ機能だけを有効にし、アドレスを割り振っています。ただ、この記事を書いている途中で、「IX2015でDHCPサーバを動かしても良い」ということに気付きました。そのほうが、無駄なパケットをインターネットに流さなくて済みそうです。現状では、スイッチを通過できないパケット(DropboxのLAN syncパケットとか)を流してしまっているし、機器の監視もやっていません。これをなんとかするついでに、DHCPの設定もしようと思います。

以上によって一部パケットは通らないものの、L2「っぽい」接続性を確保できました。実際の「VPCルータ」では、Proxy ARP(またはそれに準ずる機能)に反応するIPアドレス帯の境界を2のべき乗に依らず設定できたりします。そのため、より複雑なことが行われていそうですが、おそらくきっとたぶん問題ありません。

なお、作業を行う上で、下記サイトが参考になりました。

導入後

導入して、「通信環境がセキュアに」、「どこからでも自宅ネットワークにアクセスできるように」なりました。さらに、スループットが気になるので、計測してみます。

まず、VPN接続済みの「さくらのクラウド」とアパートの間のスループットを iperf3 で計測します。さくらのクラウド側がサーバで、その他のオプションは、全てデフォルトです。帯域は、さくらのクラウド側の「共有セグメント」が100Mbps、IX2015も100Mbps、iperfのクライアント側NICも100Mbps、アパートの上流もたぶん100Mbpsなので、全体で100Mbpsです。

この条件で、1時間に1回、土日に計測を実施しました。なお、諸事情により土曜日はUSB接続のNIC、日曜日はオンボードのNICに繋いでいます。結果はこれです。
iperf
「夜中はスループットが落ちますね」、という結果になりました。

ただ、私は自分のサーバとiperfで通信するために、VPNを構築したわけではありません。実は、体感で「GoogleMapの表示が早くなった」「Google画像検索の表示も早い」と感じていました。そこで、speedtest.net を用いた検証を行ったわけですが…「VPNを経由した場合は、そうでない場合に比べ1~2割ほどスループットが減少する」という結果になりました。

「GoogleMapの表示も別に早くなっていない、気のせい」という可能性もあるのですが…。せっかく、「改善しましたね!アパートのルータは、センチュリーシステムズ製らしく、キャッシュ機構的な何かが働いているのかも?YAMAHAのファストパスのような?」とか「今まではNAPTのセッション数を使い果たしていたのかも?でもVPNだと理想的には1セッションでまかなえるかな?」という文言を考えていたのに。でもこれ、speedtest.net みたいな計測サイトだと無意味ですね。無駄な測定をしてしまった。PhantomJSとか使って、実際にGoogleMapやGoogle画像検索にアクセスしてみれば良かったかな。

おわりに

さくらのクラウドのIPアドレス、2chにbannedされていてすごい。

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>