さて、自宅インターネット環境をSoftbank Airに変えて半年。外部からのアクセスを実現するため、SoftetherでのVPS経由のVPN構成を構築していましたが、どうにも通信が安定しません。というわけで、改善しました。
どうにも安定しません。VPNを張って、自宅サーバーのWebを見るとかすると、時間かかるし、ターミナルログインしても、息をつく感じがある。これはなんだろう、と思っていました。
Softbank Air導入期。VPSでVPNを使って自宅LANへアクセスしてみた。
そこで、vpnbridgeのログを見てみると、なんだかエラーが出ています。
2015-07-26 16:30:03.212 [HUB “BRIDGE”] セッション “SID-LOCALBRIDGE-1”: エラー: 物理的な Ethernet インターフェイス “br1” の MTU は現在 1514です。2000 バイトの Ethernet パケットを送受信するため MTU を 2000 に設定することに失敗しました。この物理的な Ethernet インターフェイスおよびデバイスドライバが 1,514 バイト (ペイロード部分: 1,500 バイト) を超える Ethernet パケットの送受信に対応していない可能性があります。その場合、サイズの大きなタグ VLAN パケットの送受信はできません。物理的な Ethernet インターフェイスの種類を Jumbo Frames に対応したものに交換するか、デバイスドライバをアップデートしてみてください。また、オペレーティングシステムやデバイスドライバの設定で、Jumbo Frames を許可してください。
おう、なるほど、Jumbo Framesか。ただ、基本外部との通信がある前提で、Jumbo Framesはすべて切ってある（むしろMTUは減らしている）はずなのに、なんだろう、という感じでしたが、おそらく原因はこれっぽいので、対策を検討します。
まず、自宅vpnbridgeサーバーですが、仮想サーバーを兼ねているので、仮想bridgeが物理インターフェースになっています。だからIF名がbr1です。まずはインターフェースドライバe1000eでジャンボフレームを有効にする方向でやってみました。最新ドライバをintelのWebからダウンロードして、コンパイルしてインストールして再起動してみました。結論：失敗。これどうにもBIOSでジャンボフレーム切ってるような感じ。あとで調べよう、ということで、この方法は却下。
そこで、改めてGoogleさんで調べてみると、この、ブリッジ先を物理IFにするのではなく、tapを介すれば良いらしいという情報を発見。
ローカルブリッジの設定で、従来は、「LANカード」でbr1のIFを選択していましたが、これをtapデバイスを新しく作る方法に変更しました。
tap_vpnserver Link encap:Ethernet HWaddr 00:AC:95:D5:38:AB
inet6 addr: fe80::2ac:95ff:fed5:38ab/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:98026 errors:0 dropped:0 overruns:0 frame:0
TX packets:191273 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:5293180 (5.0 MiB) TX bytes:30463339 (29.0 MiB)
これを改めて、brctlで接続したい仮想ブリッジbr1に接続します。
# brctl addif br1 tap_vpnserver
要するに、vpnbridgeもqemuと同様、tap経由で仮想ブリッジに接続する構成にするということです。
で、結果、通信がすこぶる安定し、エラーも出なくなりました。確かに、元々の設定でbr1に接続する構成って、論理的に不自然な構成になっていた気がします。いやしかし、仮想ブリッジとtapデバイスって、万能すぎるなぁ、と。
コメント