Tweet

第2回　SLB-PTでWebサーバをさくっとIPv6対応に

検討事項1：MTUに関連する考慮

　MTUは悩ましい問題です。IPv6では、経路途中のルータでのフラグメントによる負荷をなくすという目的のため、経路上のルータでフラグメントせず、エンドツーエンドで経路上の最も小さいサイズのMTUに調整する実装となっています。

　MTUやMTUの調整方法に関するIPv4とIPv6間の違いを、表1にまとめてみました。

　AXシリーズのようなSLB-PTを行うロードバランサは、IPv4の世界とIPv6の世界の間に立ち、両方の世界のMTUのハンドリングを行います。基本的にはICMPv4 Path MTU DiscoveryやICMPv6により、デバイス側で自動的に調整してうまくやってくれるはずです。しかし機器の実装やネットワーク環境（例えば途中のルータでICMPのフィルタがされているなど）によっては、問題が発生する場合もあり得ます。

　対応方法はそれぞれのケースに合わせて考える必要がありますが、問題が発生した場合の最終手段としては、IPv6のMTUサイズを最小の「1280」にしてしまうという方法もあります。これにより通信上のエラーは解決できますが、一度に送信できるデータ量が少なくなってしまうので、通信効率は下がります。

検討事項2：L7ヘッダやそのペイロードのリライト

　今回紹介するケースでは、IPv4のWebサーバに対して、IPv6端末からロードバランサを介してアクセスしています。

　もし、Webサーバが返信するコンテンツ中のハイパーリンク先がIPv4サーバであった場合、そのハイパーリンクをクリックすると、IPv6端末からIPv4サーバに対してアクセスしようと試み、通信エラーが発生して結局リンク先に飛べなくなる、といった問題が発生します。これでは、一時的にアドレスが変換されたとしても、実用上は使えないに等しい状態です。

　もしハイパーリンク先がIPv6サーバとなっているのであれば、何も気にすることはありません。しかしハイパーリンク先がIPv4サーバであった場合には、間に立つSLB-PTを行うロードバランサで、ハイパーリンク先のホスト名のリライト（書き換え）を行い、IPv6サーバの名前へ書き換えることで対処が可能です。つまり、Webサーバのコンテンツを変更することなく対応できます。

　例えば、コンテンツ中のハイパーリンク先が以下のIPv4 Webサーバ（www.a10networks.com）になっていた場合、IPv6 Webサーバであるipv6.a10networks.comに書き換えます。

<A href=http://www.a10networks.com/new.html> </A> 
↓
<A href=http://ipv6.a10networks.com/new.html> </A>

　なお、例として挙げているAXシリーズでは、aFleXというTclベースのスクリプト言語をサポートしています。このaFleXを利用することで、コンテンツの中身を引っ掛けてリライトすることが可能です。

　以下は、上記の場合のaFleXのサンプルです（ipv6linkという名前でスクリプトを保存します）。

when HTTP_RESPONSE { 
if {[HTTP::status] == 200} { 
HTTP::collect [HTTP::header Content-Length] 
} 
} 
when HTTP_RESPONSE_DATA { 
regsub -all "http://www" [HTTP::payload] "http://ipv6" newdata 
HTTP::payload replace 0 [HTTP::header Content-Length] $newdata 
HTTP::release 
} 

　こうして作成したスクリプトを、Virtual Portの設定に追加します。

slb virtual-server vir2 2001:db8:1:1::1 
port 80 http 
      source-nat pool pool1 
      service-group sg-80 
      aFleX ipv6link 

　こうすることで、Webサーバのコンテンツを直接編集する必要なく、前段のAXシリーズでハイパーリンク先をIPv6サーバへ振り向けることが可能になります。

　なお、オリジナルのコンテンツはIPv4 Webサーバで書かれていますから、IPv4端末からのアクセスの場合には書き換えは不要です（aFleXはVIPにバインドしていますから、IPv4のVIPにはこのaFleXをバインドしなければいいのです）。

　今回はWebサーバを例に挙げているため、このようなハイパーリンクのリライトが必要となりました。しかし、例えばVoIPや仮想デスクトップのような他のアプリケーションには書き換えが不要であったりします。逆に、特殊なALG（Application Layer Gateway）機能により、アプリケーションごとの特殊なヘッダやペイロードの書き換えが必要になることもあります。使用する機器により可／不可がありますので、利用シーンに合わせて事前の機能確認が必要となるでしょう。

検討事項3：IPv4←→IPv6間の変換ログの保存

　通常の運用では、セキュリティの観点から、Webサーバに誰が、いつ、どこからアクセスしてきたかをトレースするためにアクセスログを取っているかと思います。

　ところがSLB-PTでは、Source NAT（ソースアドレスの書き換え）が必須になります。そのままではログを取る対象はSource NATされた後のもので、すべてのソースIPが同一になってしまいます。このままでは、アクセスしてきた端末を特定できません。

　そこでSLB-PTでは、何らかの手段でログを採取する機能を備えるようになっています。AXシリーズの場合は、以下の方法を提供しています。

（1）Webサーバ側でアクセスログを取得する方法
（2）Syslogサーバ側でアクセスログを取得する方法

■（1）Webサーバ側でアクセスログを取得する方法

　AXシリーズでは、HTTPヘッダ中の“X-ClientIP”というフィールドに、Source NAT変換される前のオリジナルのIPv6アドレスを格納して送信できます。これによりIPv4 Webサーバ側で、どのIPv6端末がアクセスしてきたかというログを採取できます。

slb template http clhttp 
    insert-client-ip 
slb virtual-server vir2 2001:db8:1:1::1 
    port 80 http 
      source-nat pool pool1 
      service-group sg1 
      template http clhttp 
!

　この際、Webサーバ側にも設定が必要になります。Apacheの場合、Httpd.conf内のLogFormatディレクティブに以下の内容を追加します。

%{ヘッダ名}i

　デフォルトでは「X-ClientIP:」というヘッダが追加されるため、以下の赤字部分を追加します。なお下記の例では“（ダブルクォーテーション）で区切っているため、「\"」を両側に追記しています。

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" \"{X-ClientIP}i\" " combined

　この結果、Webサーバ側で以下のようなログを取得できるようになります。

192.168.0.254 - - [15/Feb/2011:13:04:24 +0900] "GET / HTTP/1.1" 200 12 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C)" "2001:db8:1:1::250" 
192.168.0.254 - - [15/Feb/2011:13:04:27 +0900] "GET / HTTP/1.1" 200 12 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C)" "2001:db8:1:1::250" 

■（2）Syslogサーバ側でアクセスログを取得する方法

　先に紹介したWebサーバ側でのアクセスログの記録が可能なのは、L7でロードバランスを行っている場合だけです。では、L4でロードバランスを行う際にはログを取得する方法がないかというと、そうではありません。L7ヘッダのリライトはできませんが、AXシリーズからSyslogサーバにログを送信することで取得は可能です。

! 
slb server logserver a.b.c.d ……（1）
port 514 udp 
! 
slb service-group group-syslog udp ……（2）
member logserver:514 
! 
ip nat template logging logtemp ……（3）
log port-mappings both 
service-group group-syslog ……（4）
include-rip-rport ……（5）
! 
slb virtual-server vir2 2001:db8:1:1::1 
template logging logtmp ……（6）
port 80 tcp 
source-nat pool 

　各設定の意味は以下の通りです。

（1）ログサーバをSLBのリアルサーバのように作成します。
（2）サービスグループを作成します。
（3）ロギングテンプレートを作成します。ここで「severity」「facility」などを設定できます。defaultではlocal0、debuggingで送信されます。
（4）サービスグループを指定します。
（5）このinclude-rip-rportを設定すると、どのIPv4サーバへ送信されたかをログに記録します。
（6）バーチャルサーバの配下にロギングテンプレートをバインドします。

　AXシリーズの場合では、このような設定を行うと、Syslogサーバに次のようなログが送信されます。

Feb 16 12:39:26 ax19 NAT-TCP-C: [2001:db8:1:1::250]:58070 -> 192.168.0.254:2134 RS 192.168.0.1:80#015#012<135>Feb 16 12:39:28 ax19 NAT-TCP-F: [2001:db8:1:1::250]:58070 -> 192.168.0.254:2134#015 
Feb 16 12:39:38 ax19 NAT-TCP-C: [2001:db8:1:1::250]:58071 -> 192.168.0.254:2135 RS 192.168.0.2:80#015#012<135> Feb 16 12:39:40 ax19 NAT-TCP-F: [2001:db8:1:1::250]:58071 -> 192.168.0.254:2135#015 

　このように、IPv6端末のIPv6アドレスがログとして残っていることが分かります。また別の方法として、先に紹介したaFleXを使ってログを取得する方法もあります。

when SERVER_CONNECTED { log "Connected: [IP::client_addr] ([TCP::client_port]) -> [IP::server_addr] ([TCP::server_port])" } 

　このルールをvPortにバインドします。

slb virtual-server vir2 2001:db8:1:1::1 
port 80 http 
source-nat pool pool1 
service-group sg1 
aFleX ipv6-log

　するとAXシリーズ上のログとして、次のように表示されるようになります。

Dec 8 12:10:28 ax32 a10logd: [AFLEX]<6> Connected: 2001:398:2:1::114 (38634) -> 192.168.0.1 (80) 

端末に先を越される？ サーバのIPv6対応

　最近リリースされているPCでは、OSの多くがネイティブでIPv6対応となっています。またルータやL3スイッチも、多くがデュアルスタック対応となってきています。そういう意味では、徐々にですが、企業内イントラネットのユーザーデバイス／ネットワーク機器の更新に伴い、あらゆるものがIPv6対応となっていくでしょう。

　残すはサーバのIPv6化です。しかし、技術的にはサーバ自身でIPv6化はできたとしても、どうしてもホストしているアプリケーションの改変が必要であったりして、なかなか踏み込めないこともあるかもしれません。

　また、いきなりすべての端末がIPv6になることもありません。どうしてもIPv4とIPv6が共存する期間というのが存在します。両方の端末からのアクセスに対応するためにIPv4とIPv6対応のサーバを別々に用意するというのもナンセンスではないでしょうか。

　今回ご紹介したSLB-PTは、既存のIPv4サーバをうまく利用して、IPv4／IPv6、両方の端末へのサービスを一元的に提供する1つの手段にもなります。興味を持った方はぜひ試してみてください。

第2回　「SLB-PTでWebサーバをさくっとIPv6対応に」
	Webサーバに手を付けずIPv6対応 対象となるネットワーク NAT-PTの設定方法
	検討事項1：MTUに関連する考慮 検討事項2：L7ヘッダやそのペイロードのリライト 検討事項3：IPv4←→IPv6間の変換ログの保存 端末に先を越される？ サーバのIPv6対応

「Master of IP Network総合インデックス」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）