konata.net の鯖はpfを導入していて、鯖に送られる余計なパケットはここで落とされる。
鯖の前にはNECのWR8700Nがいて、やっぱり余計な通信は落としてる。

今のところ、SSLの443番ポートはkonata.netの鯖に回していて、
鯖のpfで、勤務先のIPだった場合は、stoneを通したSSLトンネルからSSHで接続が出来るようになっている。
それ以外のIPの場合はApacheが要求を受け取り、SSL対応ページを返す。
（とは言っても、SubversionれんたるのSVNとやり取りする時以外には使っていないけど。）

で、こっからが本題。
先日、勤務先でProxy鯖が落ちて復旧まで別回線でアクセスする事になったのだけれど。
当然、この別回線のIPはkonata.netの鯖に登録されていない。
ということで、勤務先からのSSL/SSH通信ができなくなってしまった。

とりあえず、その日は諦めて、帰った後IPを追加で登録してSSHで接続できるようには
なったのだけれど、この状態は結構頼りない。

というわけで、動的にポートを開ける仕掛けを作ることにした。
紆余曲折して実装した機能は以下のとおり。

流石にやり過ぎなような気もするけれど、まぁ、穴を開けるんだからこのくらいの
仕掛けは必要だろう。
本来は、３と４についてはSSLで暗号化しないと危険なのだけれど、
勤務先からも穴を開けたいが為に、HTTPを使っている。
１のメールの方も暗号化をかけた方がいいのかもしれない。

まぁ、企業と違って取られて困るデータがあるわけではないので、
ある程度の所で利便性と折り合いを付けなければいけないけれど。

実は、konata.netのIPがBBQで焼かれてしまった後は、
今までの、2ch.netへの直接アクセスから、
このエントリで、見つけた有志の串にアクセス要求を投げていただけだったのだけれど、
残念ながらこの有志の串は、運用終了とのこと。

IPを２つ持って出口専用のIPを定期的に繋ぎかえるという方式は、
すごくシンプルで綺麗な解決法だと思う。
難点は、マルチセッションでIPを2つ貰うにはそれなりのコストが掛かることくらいか。

ともかく、その串は使えなくなったので、別の方式を考える必要が出てきた。
あまり書きこまない自分には需要は薄いのだけれど。

と言うわけで、使える串を探す旅に出ることに。
が、これが結構難題で、けっこうな数の串はすでにBBQされているし、
GETは通しても、POSTは通さない串も居たりする。

最初は、stealthyというFireFoxのアドオンの持ってるプロクシリストをそっくり頂いて、
試してみたのだけれど、見事に全部使えない串だった。

で、結局代わりになるような物が見つからないので、torに頼ることにした。
一時期、荒らしに使われたとかで、結構な数のノードが規制されたと記憶しているのだけれど
鯖を見繕った感じ、まだ幾つかは使える物があるようだ。

が、こっちもこっちで割と制限があり、なんでもかんでも使えるわけではなくて、
80番ポートが使えること、REMOTE_HOST名に”tor”を含んでいないこと、
BBQされていないこと、torノードから拒否されていないこと、
等々の条件を満たしたノードというのはそんなに多くない。

膨大にあるノードについて一つ一つ手で試すのはキチガイの所業なので、
実際はスクリプト組んでリストアップする作業をさせるのだけれど、
それでも結構な時間がかかる。

次に、torはsocksプロクシとして動作するので、
socksでhttpを流すことの出来る環境が必要になる。
このために、dante(socksify)を導入した。
当初は、phpから socksify を叩くように作っていたのだけれど、
ここで、tor経由の場合のみphpのget_file_contents()がおかしな挙動をする事象が発生。
具体的には、要求を投げた後、帰ってくる前に勝手に要求を５回再送してエラーを応答する。
どうやら、応答に時間がかかると、送信エラーとみなして勝手に要求を投げ直すらしい。
そんな身勝手なことされても困るんだが……
結局、この部分でphpを使うのは諦めて、wgetを導入することにした。
wgetは名前のイメージとは裏腹に、POSTメソッドを投げることが出来る。

また、2chの方でも、Cookieに設定するHAPの払い出し条件を厳しくする等の対処が
取られたようで、そういったCookieの設定値に対する対処も新しく加えなければならない。

作業を終えた今だから気楽に書けるけれど、正直相当めんどくさかった。
これで、2chが仕様を変えて海外からのアクセスを全部拒否するようになったら、
相当脱力すること請け合いである。

ともあれ、臨時用２ch串はなんとか再び使えるようになり、一件落着。
後は、torのノードが逐次誕生して、それらがBBQされないことを祈るのみである。

7/13日。午前11時ちょいすぎ。

いつものように、会社からkonata.netの鯖に繋いで、
作業・実験をしていたのだけれど、
ちょっとstoneの接続オプションを変更したい事態に陥った。

stoneは会社からSSLトンネル掘って接続するのに使ってるので、
いつものように、プロセスKILLして再立ち上げ。ってのが出来ない。
KILLした時点で接続切れるので。

というわけで、なんの気なしにrebootかけた。

が、konata.netの鯖にはニコイチBOXが接続されており、
ニコイチBOXが接続されていると鯖のBIOSが立ち上がらないという事象が発生する。
こうなった場合、ニコイチBOXの電源を切って鯖を立ち上げ直しする以外に
復旧の手段はなく、あえなく、konata.netの鯖は沈黙した。

自分で落としたんだからそりゃ落ちる。

で、忘れてrebootしたのは実は初めてではなく過去に全く同じパターンをやらかしている。
これは、人としてまずいよなぁ……

というわけで、ニコイチBOXが接続されている時にはrebootコマンドを使っても
rebootしないように、一枚スクリプトを被せることにした。
で、.cshrc に alias で カバースクリプトを実行するように記述を追加。

適当に試して適用完了。

なんとなく、最近アクセスが増えてきてていや～な感じはしてたんだよなぁ。

会社からプロクシ使って書きこもうとしたらプロクシ規制にひっかかってやんの。
で、ちょろちょろと調べる。

どうやら、「焼き部隊登録リスト」という分類でBBQに登録されているらしい。
焼き部隊なんてやってなんのメリットがあるのか知らないけれど、
まぁ、あるんだからしようがない。

xxx.xxx.xxx.xxx.niku.2ch.net. 2048 IN TXT “shutouted IP: xxx.xxx.xxx.xxx”

みたいな感じで登録されているようだ。
で、２chでの使われ方を調べる。

今年の頭に、「bbs.cgi完全パック.zip」なるものが出回り、
２chの板CGIのソースが漏れたのを思い出して、適当にダウンロード。
ソースを「BBQ」で引っ掛ける。
Perlはきちんと読めないのだけれど、どうやら２chが参照するDNSに登録されて、
書き込みの時に２chのDNSを参照。
BBQされているホストは、127.0.0.2が帰るようになっているようだ。

この登録を解除すればいいことになるけれど、
ぶっちゃけ公開プロクシなので解除されるはずがない。

2chの鯖にログイン出来たら、ちゃらっと情報消して遊べるのになぁ。と、
鯖一覧を眺めて、なんの気なしにsshでアクセスしたらパスワード入力まで行ってしまった。
これ、危ないんじゃないかなぁ……
まぁ、2chがザルでも自分が困るわけじゃないからいいか。

で、どうするか。
可能性としては幾つか考えられるけれど、本格的な対処というのは難しい気がする。
結局IPを持ちまわってのイタチごっこなので。
とりあえず、暫定対処をして急場を凌ぐことにした。

といっても、食いモンの方ではない。残念。

konata.netはFreeBSDで動いていて、個人用にメールサーバが動いている。
このメールサーバにメールのキューが溜まってるよ。とrootアカウント宛に届くdaily run outputのメールに通知が有ったのが6月4日の事。
554 Error: too many hops
なんてエラーをいただいてしまった。
が、当然土日はやる気がないので放置する。

月曜になって、なんとなく放置もアレな気がして、
メールキューに溜まったメールの見方を調べたりする。
で、肝心のメールはというと、いわゆるSEO系のSPAM。
ヘッダを眺めると、どうも、サブドメイン当てに届いたメールを、
自鯖では自分宛てではないと思って、リレーホストに転送して、
リレーホストは、いや、お前んとこだろ、と転送して～を繰り返しているうちに
転送の制限を超えたらしい。

とりあえず、サブドメイン作った分はメールを受け付けるように変更。
それにしても、国外からのメールは弾いてるのに何処からやってきたんだろうと
ヘッダを見るとgoo.ne.jpからだと仰る。
ん～、フリーメール系の鯖も弾いた方がいいのかなぁ……