IPSecVPNを設定。双方のセグメントにあるホストへPingがきれいに通り、無事開通、と思ったのもつかの間。リモートサイトにある端末からローカル側のサーバにHTTPでアクセスできません。

私の作業用PCで確認したところ、サクサクに動いてます。が、お客様のPCではNGです。どうやっても繋がりません。Pingは通るのに。

作業用PCとIPアドレスを入れ替えてもNG。お客様のPCをリカバリにかけてみてもNG。

時間をおいて、会社から違うPCを持ち込んだところ、これまたサクサク動く。

完全に手詰まりです。

基本に立ち返ってWiresharkでパケットキャプチャしたところ、[TCP segment of a reassembled PDU]の嵐。

ここでようやくMTUサイズ問題だと気づきました。

ルータでMTUを大幅に下げたところ、あっさりと接続。めでたしめでたしです。

しかし、どうして作業用PCや社から持ち込んだPCではOKで、お客様のPCではNGだったのか。

どうやら、Path MTU Black Hole Detection機能が関係しているようです。

Configure TCPIP stack settings in Windows NT にある

To configure Path MTU Black Hole Detection:

[HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \Tcpip \Parameters]
EnablePMTUBHDetect = 0 (Enabled = 1, Disabled = 0, Default = 0)
Note Windows 2003 SP2, Windows XP SP3 and Windows Vista enables black hole detection by default, and changes the PMTU to 536 bytes if retransmissions occurs (If the following retransmission also fails then the PMTU is returned to its original size). More Info MS KB Q925280
More Info MS KB Q136970
More Info MS KB Q159211
More Info MS KB Q314825

このあたりの記述にヒントが。NGだったお客様のPCはWindowsXPSP2、持ち込んだPCはVista、作業用PCは7でした。

どうやらOKだった端末はMTUサイズのエラーを検知して、自動的にMTUを縮めていたようです。

なまじ接続が出来るPCがあったもので、解決までかなり時間がかかってしまいましたが、理屈の通る現象で一安心です。

http://support.citrix.com/article/CTX120926

これに合致していた。

このHotfix Rollup Packをインストールすると、ICAファイルのパラメータTcpBrowserAddressではなくHttpBrowserAddressが使用されるようになります。ただし、デリバリーサービスコンソールで作成されるICAファイルには、デフォルトでSSLEnable=ONが指定されます。このため、ICAファイルでサーバーポートとして80を指定すると、アプリケーションが起動に失敗します。この問題を避けるには、サーバーポートとして80を指定する場合はICAファイルをSSLEnable=OFFに変更してください。[#214876]

作成したICAファイルをNotepadで編集して、SSLEnable=OFFとしたところ無事起動した。

「TCP/IP+HTTPブラウスのチェックボタン」をオフにして作成した場合、TcpBrowserAddressだけしかエントリが無いので起動に失敗する。HttpBrowserAddressを追記してやれば起動に成功する。

つまり回避方法は２通り。

1. 「TCP/IP+HTTPブラウスのチェックボタン」をオンにして作成した場合はSSLEnable=OFFにする。
2. 「TCP/IP+HTTPブラウスのチェックボタン」をオフにして作成した場合はHttpBrowserAddressを追記する。

チェックボタンの有無はXenAppサーバの検出時、ICAクライアントからブロードキャストが送信されるかどうかの違い。オフにするとブロードキャストで検出を試みる。このためネットワークトラフィックが発生するので、基本的にはオンにしてICAファイルを作成する。詳細は以下。

http://support.citrix.com/article/CTX114457

で、切り替え。通信出来ない…。

散々こねくり回したけど全くダメ。

で、PingをISPに投げてやると…。

通った。通らないサーバも同様にPingを投げると通っていく。

xlateやarpのエントリの加減なんだろうか…。

XenAppサーバにインストールしていたんですが、別のサーバにインストールしてみるとアッサリ動いてしまいました。

XenAppのライセンスサーバにWeb Interfaceをインストールしてます。

XenAppサーバのインストールの時、IPSEC Serviceが無効になっているとインストール途中で失敗するという罠もあります。

私はIPSEC Serviceを無効にしがちなので、ハマりました。

管理用DBがmdbからSQL Server Expressに変更されたから、というのが理由。

回避策として、vCenter用の仮想マシンを立てた。

#DHCP

#dhcp relay server-group 0 ip 192.168.1.1

vlan interfaceで設定

#dhcp select relay

#dhcp relay server-select 0

斜体の0は0から9までの間で自由に設定する。

1. ESX3.5が稼働している環境で仮想マシンを作成
2. vCenter ConverterのBootCDで仮想マシンをブートさせ、VMware Server向けの.vmdkにコンバート
3. 社内に持ち帰ってVMware Serverにインポートして色々設定
4. 再びvCenter ConverterのBootCDでコンバート
5. Converter Standaloneで、仮想マシンをESX3.5にインポート

ざっくりとした手順はこんな感じです。

vmfsデータストアから直接FTPやSCPでダウンロードする方法がありますが、ESXのバージョン違いなどでトラブルがありそうなので、Converterを利用することにしました。

コンバートしたvmdkはUSB-HDDで運びましたが、帯域さえあればネットワーク越しで運べるので、改めて仮想化のメリットを感じることが出来た仕事です。

サーバのインストールとアプリケーションの公開方法までは簡単ですが、どう設定していくのか、という部分でコツが要るんだろうな…という印象です。

目的はMilkSyncを使ってS21HTのToDoと連携することでしたが、やはり便利。

以前に試用版を使ってみた時に比べて、タスクの量が多かったせいか一発目の同期では失敗しました。

何度か試してみたんですが、感覚的には一気に10個以上のタスクを「終了」させて同期すると失敗する様子です。

運用でカバーだ。

一方で、SQLServerのAWE機能を使うと32bitOSの4GB上限を超えられるが、
現実的には32bitのWindows Server 2008 Standardでは意味をなさない。
2008 Enterpriseは32bitでもメモリ上限は64GBとなっているため、AWEを利用することで4GB以上のメモリを利用できる。

4GB以上のメモリをSQLServerで利用するには、64bitのServer 2008 StandardでSQLServer 2008 Standardを利用すれば良い。
今判らないのは、この場合、SQLServerのバージョンは32bitか64bitか、どちらを使うべきなのか、あるいは使えるのか、ということ。

ちなみに、hpのサーバの場合、プリインストールモデルでは32bitと64bit双方のOSインストール用メディアが付いてくるので、再インストールの手間はかかるけど、簡単に試すことができきる。