以前、Windows7を導入した際の記事で、Cisco VPNクライアントが64bitOSに対応していない～と嘆きましたが、どうもCiscoが対応したらしい。
これを知ったのは、付き合いのある米国の会社サポートから「64bitに対応したから使えや」というメールが回ってきたからである。
どれどれ使えるんかしらん？とWindows7-64bitにインストール＆設定ファイルをインポートし、接続してみると無事米国ネットワークと開通。

「うひょ～、これでこれだけのために32bitOS立ち上げる必要無くなったワイ」

Ciscoのダウンロードサイトにもbeta版があるので、ログインアカウントを持っている方は落とせると思います。
ちなみに、バージョンは「5.0.07.0240」です。

このブログサイトのLogwatchから不穏なログが通知されてきた。
「apache脆弱性攻撃と思われるアクセスがありましたよ～」
で、中を見るとこんな感じ。（IPの最後はとりあえず隠しておきますです）

A total of 1 sites probed the server
119.63.198.xx

A total of 1 possible successful probes were detected (the following URLs
contain strings that match one or more of a listing of strings that
indicate a possible exploit):

/wordpress/tag/\xe3\x83\xa1\xe3\x83\xbc\xe3\x83\xab\xe9\x80\x81\xe4\xbf\xa1/ HTTP Response 200

そこでアクセス元はというと、whoisでこの[119.63.198.xx]を見てみると、このセグメントは[Baidu, Inc.]が所有している。つまり検索サイト「百度」を運営している日本法人である。
警告を超意訳すると、「成功したっぽい探査が見つかったよ～、下記のURLで１つ以上の脆弱性攻撃の可能性を示す文字列リストが含まれてやんす」と。（この訳は役に立たないのでご自分で訳してくださいな）
それで、問題のURLを見ると・・・、
「あぁ～、タグに使われている漢字コードっぽいな～」
「ん？、なんで[\x]なの？、本来[%]じゃ・・・」
ふ～ん、「百度」クローラエンジンのリクエストURLのエンコードがバグっているものと思われますな。
UTF-8エンコードを別のエンコードに変換しているのならまだ可愛げがあるが、[\x]はねぇ～だろうよ・・・

実際、［\x］を［%］に置き換えると、
「\xe3\x83\xa1\xe3\x83\xbc\xe3\x83\xab\xe9\x80\x81\xe4\xbf\xa1」は、
「%e3%83%a1%e3%83%bc%e3%83%ab%e9%80%81%e4%bf%a1」=「メール送信」
という文字列になる。（実際タグとして使われている）

で、この変態リクエストを受け取るとどうなるかをtelnet接続で試してみると、Wordpressは404ページを作って返しているのだが、ヘッダが以下のようになっている。

# telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /wordpress/tag/\xe3\x83\xa1\xe3\x83\xbc\xe3\x83\xab\xe9\x80\x81\xe4\xbf\xa1/ HTTP/1.1

HTTP/1.0 404 Not Found
Date: Sun, 28 Jun 2009 01:24:44 GMT
Server: Apache/x.x.xx
X-Powered-By: PHP/5.2.9
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Last-Modified: Sun, 28 Jun 2009 01:24:50 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache
Connection: close
Content-Type: text/html; charset=UTF-8

「ほぇっ？、HTTP 1.1 対応のエラーコードが帰ってねぇ~！」
ってことは、変態URLに伴う404ページが、検索インデックス（検索データベース）に登録されちゃってる可能性がある、まずい・・・のか？元来リクエストのエンコードがミスっているんだろ・・・(ry
ということで、正しく404ステータスコードを返すように下記コードを、使用テーマの404.phpに追加。（get_header()の前）

<?php header("HTTP/1.1 404 Not Found"); ?>
<?php header("Status: 404 Not Found"); ?>

で、どうなったか。

telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /wordpress/tag/\xe3\x83\xa1\xe3\x83\xbc\xe3\x83\xab\xe9\x80\x81\xe4\xbf\xa1/ HTTP/1.1

HTTP/1.1 404 Not Found
Date: Sun, 28 Jun 2009 01:42:30 GMT
Server: Apache/2.2.11 (Fedora)
X-Powered-By: PHP/5.2.9
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Last-Modified: Sun, 28 Jun 2009 01:42:33 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache
Status: 404 Not Found                        <<<===HTTP/1.1用に 追加された・・・
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

ということで、ヘッダには確かな値が入ったので、あちらさんがヘッダ情報を正確に拾ってくれることを祈って、ちょっと様子見してみまひょ。
ちなみに、他のクローラ（googleやyahoo）は正常なURLエンコードでリクエストしてきてますけどね。
「あんたのところだけよ」と小一時間程問い詰めたいが、小心者なので止めとこ。

さて、前回「マルチセッション設定～その壱～」で、NetGenesis SuperOPT-GFiveルータでのマルチセッション環境におけるルーティングについて書きましたが、お次は、固定IP側へ外部から内のサーバに各種要求があった場合のルータ設定を書きますです、はい。

「IPマスカレードテーブル設定」というやつで、ようは外から入ってきた要求種類によって要求転送先を決めてあげるってことですな。（ポートフォワーディングとも言われますが・・・）

これは至って簡単。検索サイトから来た人は既に知っていることだと思うので、すっ飛ばして進んでください。例えばこのサイトを見ている人は何らかのブラウザを使っていると思います。（昔は（今も）テキストベースで見ることも出来ましたが）
その時無意識に「http://」と打っているか、見ようとしているリンク先にこのおまじないが付いていると思います。（もしくはいきなりwwwと付けてもいい場合がほとんど）
これは、「どこそこのサーバ（家）の80番ポート（部屋）に行って、要求した情報持ってこい！」という指令が出されます。すると、この指令書が届いた家の主（OS）は80番の部屋の戸を開けて待っている管理人（サービス）に指令を渡します。管理人は、「欲しいのはこの情報かい？持って行きやがれぇ～」と情報を投げ返してきます。で、帰ってきた情報をブラウザで表示させると、めでたし、めでたし、可視化されて見えるわけでやんす。（簡略化するためだいぶ飛躍した表現ですので、他のネットワークをまじめに解説したサイトを探してくださいな）
このように、サーバはいくつもの役割のポートを開いている場合がありますが、「ウェルノンポート」あたりの語句を検索してみてください。調べていくうちに、サーバのどのポートが開いているか調べたくなるかもしれませんが、軽い気持ちで絶対に他人のサーバに仕掛けちゃいけませんよ。あまりにも酷いと、アクセスログと一緒に警察に泣きつかれ、警察がプロバイダに情報開示要求を出し、人物が特定されて「お縄頂戴」になっちゃいます。

さて、本題に戻ります。こっちの方が短いと思われ・・・、だって画面をお見せするだけだから、ぉぃ。

IPマスカレードテーブル設定

「IPマスカレードテーブル設定」で、サーバが属しているセッション（PPPoE1かPPPoE2）の設定リストに上記画面のように必要なポートとその転送（変換）先をセットし、「設定の更新」をするだけです。これで、そのポートへの要求は自動的に指定したサーバに転送されます。

ではでは

前回、「固定IP（Global）げっとぉ～」の最後で、はまったことをお伝えしましたが、その第1弾です。

まず、NetGenesis SuperOPT-GFive設定での結論から。

我が家で使用しているルーターは、NetGenesis SuperOPT-GFiveなのだが、このルータはマルチセッション接続に対応しており、2つの経路を管理できるようになっている。
そこでまず、固定IPのPPPoEの追加接続は問題無く終わり、これでめでたく固定IPが割り振られ、マルチセッション環境の下地が出来たことになる。
お次は、内（LAN）からのルーティング制御である。つまり、クライアントが属するセグメントはISP（動的IP）側で、サーバが置かれているセグメントは固定IP側で制御されるように交通整理をしてあげるわけである。幸か不幸か、当方の癖で大雑把なセグメント分けは既になされており、特に個々のIPを動かすことはあまり無かったのだが、もしこの記事をご覧の方で無造作にIPを割り振っているのならば、今のうちに整理した方がいいと思われ。さて、当方のセグメント分けもクラス（A,B,C）で分けているわけではなく、1つのクラスの一部を分断しているだけである。（例えば、192.168.1.0/25と192.168.1.128/25で2分しているだけ）
当方の環境は、先ほどの例のセグメント前半に「サーバ群」、セグメント後半に「クライアント群」が配置されている。で、このルーターでこれらのセグメントから出ていくデータの交通整理をどうやってやるかというと、「ソースルーティング設定」で行う。セグメント前半はPPPoE2（固定IP側）セッションに、セグメント後半はPPPoE1（ISP 動的IP側）セッションにという設定を下記画像のように行う。赤丸は超重要です。必ずチェックを入れましょう。（見過ごすのは当方だけ・・・？）
当方はこれを見過ごして、数時間の間、どちらかのセッションの経路からしか出ていかず、PPPoE接続を反対にしてみたり、PPPoEのゲートウェイを切り替えたり、ソースルーティング設定を変更したりで、ルーターのリセットを何度も行いました。ISPのログには不可解なログが残っているでしょう・・・ISPの管理者の方、ごめんなさ～い。

ソースルーティング

これを設定したら、「設定の更新」を行ってルーターをリセットします。（これどうにかならんもんかなぁ～、マイクロリサーチさん・・・）
さて、これで各セグメントにいるクライアント／サーバから外部の検索サーバ等にtraceroute(Win:tracert)コマンド等を打ってみると、ゲートウェイが主回線側（当方はISP側）であるにも関わらず、ISP網側はISP側のルーティング経路、固定IP側は固定IP側の経路を通っていることが分かります。

さぁ～、これで内からの経路がすっきりしました。
が、しかし、このままではサーバ運用できません。なぜなら、外からサーバ側に入ってきたパケットを割り振る処置を行っていないので、内にいるサーバには届きません。さて、次回は「IPマスカレードテーブル設定」で内側のサーバに要求が届くよう設定してみます。

我が家のインターネット環境は、B Flet’s光を利用して、プロバイダから毎回割り振られる動的IPアドレスを使用している。
今ご覧頂いているサイトも、この動的IPアドレスをDDNSを使って名前（senjyu.dyndns.org）を付けて公開している。
また、内部に仕事で使っているアプリケーションサーバが何台か立ち上がっており、外出先で突然デモを行うときがしばしばある。まぁ、常時接続なのでそうそう割り当てられたIPが変わることは無いし、プロバイダ側のラインがメンテ等で日中不通になることも無いのだが、もしもの場合 再接続後DDNSの更新まで最長5分のアクセス不能という空白時間帯が出来る。なので、いつもちょっとヒヤヒヤしながらデモしているのが現状。それに、内から外（外から内）のルーティングが、サーバー側もクライアント側も一緒なので、それを分離したいと前々から思っていたのも事実。
そこで、21ip.jpさんでサービスしている固定IP発行サービスを利用してバックラインを作ることにした。（既に光網に接続しているので、1IP発行サービス[月額税込：2,100円]を利用）
発行依頼が日曜日（昨日）であるのに関わらず、依頼から90分程度で発行完了＆PPPoE接続情報が送られてきた。

さて、これでルーター設定をちょっと弄れば、

「さぁ～、これでハピィハピィ～」

と思いきや、やはり

「はまった・・・」

そうです、だ～れのせいでもありゃしない～♪、みんなおいらが悪いのさぁ～♪・・・orz （古

続きは後で。