written: 2013-12-25 .. 2019-02-16
au ひかり用HGW の BB ルーターによる置き換えには制限があります。au ひかり電話を利用しない場合、HGW の WAN 側 MAC アドレスを BB ルーターに偽装させることによって、置換が可能となります(MAC アドレスのみによって、端末の正当性の確認を行い、ルーターは WAN から DHCP で自動的に各種設定を拾います)。
一方、au ひかり電話を利用する場合、HGW は、DHCP によって WAN に参加した上、さらに IEEE802.1X の認証機で認証を行おうとします。おそらく、認証機の場所(IP アドレス)に関する設定も、WAN の DHCP から受け取るものと推測しますが、MAC アドレスを偽装した BB ルーターの場合は、認証機に関する情報は捨てられてしまうことになるでしょう。そのため、MAC アドレスを偽装した BB ルーターの LAN(下流)側に HGW を置いても、HGW が関与できるのは、BB ルーターの DHCP なので、au ひかりの WAN の DHCP から情報を得ることができません。これが原因で、BB ルーターを上流側に(au の WAN に直結し)、BB ルーターの下流側(LAN)に HGW を接続して、ひかり電話アダプターとして使おうとしても、HGW がエラー表示となり、HGW をルーターとして動く状態にすらできません。
非常に古い情報では、GapNAT という非常に特殊な技術によって、上流側に BB ルーターを、下流側に HGW を置いて au ひかり電話を使うことを可能にした事例があったようです。この GapNAT というのは、住友電工の特許技術である(あった?)こと、また当時の ADSL が主流だった時代、ネットワーク対戦ゲームでグローバルアドレスを必要とするゲームのために導入された技術というニーズ上の背景があったこと(おそらく今ではゲームや OS 側がソフトウェア技術的に柔軟に対応して解消した問題であると思われる)、などから、一時的な存在に終ったようです。この GapNAT の場合は、物理的に LAN 側の DMZ に接続した au ひかりの HGW を、LAN のローカルアドレス空間ではなく、WAN 側のグーバルアドレス空間にいるのと同様に稼動させられるので、上記の WAN の DHCP とやりとりして、IEEE802.1X 認証機にアクセスするという処理に支障を及ぼすことなく LAN 側に設置できることになります。現在でも、中古で GapNAT 対応の BB ルーターを入手することもできますが、所詮 ADSL 全盛時代のものであり、スループットが特に高いわけでもないので、上流側に HGW を、下流側に BB ルーター を置いて 2 段ルーター状態で運用した場合に対して、アドバンテージを望めそうにもありません。
au 公式や一般には、HGW をルーターとして使い、手持ちの BB ルーター(無線 LAN 親機としての機能を持つもの)をルーターとしてではなくブリッジ(ネットワークを物理的に接続するだけの機器)として動作させて使うというものです。これによって、HGW に(BB の持つ)WiFi ネットワークの機能を付加することができます。
KDDI から貸与される HGW(僕の場合 AtermBL170HV)は無線 LAN 親機としては非力なだけでなく、ルーターとしての機能面でも、市販されている BB ルーターに見劣りがします。なのに、HGW をルーターとして動作させ、BB ルーターの方をただの無線 LAN 用のブリッジとして動作させるのは、「豚に真珠」「陸に上がった河童」みたいな話です。
ということで、【 2 段ルーター】が最善かなと思います。
ここでは BB ルーターとして Buffalo 製の WZR-HP-AG300H を例にして設定のポイントを述べます。
このようにすることによって、BB ルーターのルーターとしての性能を最大限利用することができます。有線も無線も LAN は BB ルーターの下流側 LAN(196.168.11.x)に各機器を接続するようにすれば、ファイアーウォール等のセキュリティー機能等も BB ルーターの機能を頼って管理することができます。
HGW の LAN(192.168.0.x)に直結されているのは、(BB ルーター以外では)HGW 内蔵の au ひかり電話だけとなります。
BB ルーターに接続する各機器側の設定は、「デフォルトゲートウェイ」と「プライマリー DNS」に BB ルーターの IP アドレス(192.168.11.1)を指定しておけば ok です。
上記「au ひかり用 HGW と手持ちの BB ルーターを 2 段ルーターで併用する」の場合は、VPN を行う場合も HGW 側でポートマッピングの設定はせずに可能です。DMZ なので、あらゆるプロトコルがそのまま BB ルーターに渡されます。もちろん、DMZ にしなかった場合は、PPTP が利用する TCP (1723) と GRE (IP (47)) のパケットを HGW が BB ルーターの IP アドレスにフォワードするポートマッピング設定が必要です。
ちなみに、VPN サーバーとして、BB ルーター(例として前述の Buffalo 製の WZR-HP-AG300H)自身を使う場合の設定のポイントを紹介します。
以上でサーバー側の設定は終り。
クライアント側の PPTP の使用方法は、他の情報に譲りますが、Android 端末や Linux 端末から、外部ネットワーク経由で LAN に内側からアクセスできるようになったのを実際に確認しています。
また実用的には、DDNS サービスも併用したくなるものと思われますが、これについてもここでの主旨からは外れますので、他の情報に譲ります。
実は、上記で一応、サーバー側の VPN 環境は一応 ok となるのですが、Linux (Ubuntu) のリモートクライアントから VPN 経由で LAN 内の NAS にアクセスして、大量のアップロードを行うと、VPN が不安定になり、すぐに接続が切れてしまうということが判明しました。
これは、ルーターなどのネットワーク機器の設定の問題ではなく、クライアント側の Linux マシンのネットワークの設定に不備があったのが原因ということが判明しました。実は、このリモート環境では、WiMAX を使っており、WiMAX 回線は MTU が 1400 なのに、Linux マシン側の MTU を 1500 で稼動させていたため、大量のパケットフラグメンテーションが発生したのが原因でした。現時点で最新鋭とはいえ、掌サイズの WiMAX ルーターごときに、到底処理しきれる量ではなかったようです。
原因究明後、クライアント側 Linux マシンの MTU を最適値の 1400 に調整したところ、接続は安定化して NAS との VPN 接続に問題はなくなりました。
上記のサーバー側の BB ルーター WZR-HP-AG300H では、PPTP サーバーの設定画面で、MTU の設定もできるようになっており、よくわからなかったので、元々は最大値の 1500 で運用していました。おそらく、LAN 側からリモート側に向けての通信(ダウンロード)では、1400 を超過するサイズのパケットにフラグメンテーションが発生することになると思われますが、問題が発生しなかったのは、主にアップロードしかしていなかったからというのと、BB ルーター自体の処理能力も高いためだったのでしょう。サーバー側 BB ルーターの PPTP サーバーの MTU の設定はデフォルトで 1396 という数値になっています。1400 よりわずかに 4 バイトだけ小さい数値。おそらく、NTT 光や au ひかりの MTU と比較して最小である WiMAX の 1400 を基準にした数値と思われます。PPTP でパケットに付加されるヘッダがちょうど 4 バイトの大きさなので、データの内容物としては 1400 - 4 = 1396 が最適化されたサイズということになります。
※ MTU の設定というのは、経路上における最も狭く“ボトルネック”となっている数値を使うというのが基本になると思います。もちろん Web では、途中経路のネットワークの規格をすべて網羅するのは簡単ではないので(traceroute コマンドなどを使用すれば固定ルートの場合は把握はできなくはない)、実際にどのサイズのパケットまでが素通りできるか PING コマンドを利用して調べるのが実用的です。
<戻る>