簡易的なOP25B対応

様々な仕事が滞っている中なので、先行してメールを送れるようにだけはしておいた。

OP25Bとは、SMTPサーバーポートである25をISPが中継しない、というものだ。スパム対策だというのだが、実際は自由にメールを使わせない、メールをISPで一元化するものとなっている。

メールアカウントが提供するサーバーをそのまま使っていれば特に不自由は感じないという人もいるだろうが、近年のSMTPサーバーサービスはかなり複雑に認証され、フィルタされることもあって使い勝手は著しくよくない。以前ならそれに対する対応としてローカルなメールサーバーを使えばよかったのだが、今度はそれがISPによって蓋をされた格好になる。

各家庭でMTAから出す、ということそのものが特殊な要求と見るのかもしれないが、今はそもそもSMTPサーバーを提供しないメールアカウントも珍しくないので、やはりの必要だし、自宅でのメールサーバー公開もできない。

とりあえずシンプルな方法として、セキュアで確実にリレーしてくれるMTAが欲しい、ということで工夫してみた。

まず、VPSにPostfixを導入する。そして、次のように設定する。

inet_interfaces = localhost
mynetworks_style = host

これ以外についても適切に設定するが、これで外部からメールを受けとらないためセキュアな設定となる。もちろん、外部からメールを受けとるように設定する場合には、より広く適切な設定が求められる。

この状態ではSMTPを用いてメールを送信することができるのはVPS自身だけだ。しかし、VPSのループバックインターフェイス経由ならば送信できるため、SSHのポートフォワーディングを用いることで他のホストからのメールを中継してもらうことができる。

これには次のコマンドを使用する。

$ ssh -x -L 2500:localhost:25 remorthost.example.com

「ローカルの1024以下のポートを転送する場合、ローカルのroot権限が必要」なのであり、ここでは2500番ポートをリモートの25番ポートに転送することでroot権限なしに実現している。なお、リモートホストの名前はlocalhostにしないと、loインターフェイス経由での接続にならないので注意が必要。インターフェイスを気にしなければFQDNで指定しても接続できてしまうことがあるから、理解していないことがある。

-Lオプションのまんなかのargは、後で指定するhostが名前解決をし、接続するための名前だ。つまり、localhostを解決するのは、リモートホストで、リモートホストにとっての::1/127.0.0.1に接続される。

-nオプションを使えばバックグラウンド接続が可能なはずだが、ServerMans@VPSではそれができなかった。接続そのものが切られてしまう。タイムアウトして接続は切られてしまうし、不要なターミナルセッションが生まれてしまうが、通常通りのログインとした。

あとはMUAのSMTPサーバーとしてlocalhost:2500を指定すれば、MUAはVPSのPostfixとやりとりをしてメールを送信することになる。通信はssh(通常は22番ポート)を経由するため、25番ポートをブロックするOP25Bにはひっかからない。

VPSの活用方法としては一般ユーザーでも意味のある方法になるのではなかろうか。もっとも、セキュリティ管理などを考えれば一般ユーザーに進められる方法ではないが。

VPS * DeleGate によるフロントエンドサーバーを用いたインターネットサーバー

概要

IPv6への移行がこれほどまでに叫ばれているのに、世の中は全くIPv6に移行する気配がない。IPv4の枯渇はであり、そうなるとグローバルアクセス可能なインターネットサーバーというのは極めて難しい。重大な問題は、グローバルIPアドレスの価値が高すぎること、そしてISPが自宅サーバーを阻む方向にあることだ。

そこでよい対応方法のひとつとして、グローバルアクセス可能なVPSをリバースプロキシとして、という方法があり、さらにいえばVPNを汲むことでVPSをフロントエンド(ルーター)とするサイトを構築することも可能だ。

今回はとりあえず、「VPSを使ってインターネットにサービスを公開する」ところまで事を進めた。

事前準備

少なくともVPSと独自ドメインが必要不可欠だ。別に無料サブドメインでも問題はない。ただし、VPSは将来的にはVPNを汲むことが可能な、つまりはpppあるいはtunデバイスが利用可能なrootサーバーである必要がある。

私は今回、サーバーとしてDTI ServerMan、ドメインはXDomainを利用した。契約書を熟読するのに、何より時間がかかった。契約そのものは簡単で、特にクレジットカード決済ができる人ならあっという間だが。

そして、VPSを安全な状態にセットアップするまでがまた一手間。基本的手順としては、

  • 一般ユーザーを作る
  • 一般ユーザーのパスワードを強固なものにする
  • SSHのポートを変える
  • rootパスワードを強固なものにする
  • usermodでwheelグループに追加
  • visudo
  • FirewallをConnected/ICMP/SSHのみ透過するように変更
  • アップデート
  • 不要なサービスを止める

といったところになる。CentOSでのこうした個々の作業は情報が豊富なので、私は繰り返さない。各自調べてほしい。

この状態では基本的に何もできないので、サーバーを停止しておいたほうが安全である。

レジストラの方でリゾルバの設定(DNSレコードの設定)を行えばVPSに名前でアクセスできるようになる。普通はここで、VPS自身でサービスを起動し、ファイアウォールを設定してサービスを提供する。

私はとりあえずXDomain側でサービスを開始した。XDomainで設定しても独自ドメインでのサービスは提供できるのだが、フルカスタマイズはできないし、将来的にフロントエンドの変更が生じる場合があるので、やめておいた。

DeleGate

DeleGateは汎用のプロキシデーモンだ。HTTP/FTP/NTP/NNTP/Socks/SSH/SMTP/POP3/IMAP4などのアプリケーションゲートウェイ(リバースプロキシを含む)として機能するばかりでなく、ネットワークレベルゲートウェイとしても機能する。つまり、TCP/UDPパケットを転送することも可能。単純にこれをリバースプロキシとして動作させるだけでもかなり多くのサービスが提供できる。

ただ、CentOSにはDeleGateのパッケージがない。かつてはプロキシサーバーといえば、というほど有名だったが、今はマイナーなようだ。そこで手動導入したのだが、思わぬ問題が立ちふさがった。テスト環境はx86_64で、本番環境はi586ということが判明し、同じパッケージが導入できないのだ。そこで、本番環境はRPMで導入、一方テスト環境は

yum install gcc gcc-c++ make openssl-devel
# wget URI
# tar xvf file
# cd delegate9.9.8
# make
# cp src/delegated /usr/local/sbin/

これで最低限動作はするようになる。セキュリティや細かな設定は別として。

さて、テスト環境では

delegated -P 80 MOUNT=”/journal/* blogURI/*”

で動作してくれたのだが、本番はそうはいかず、checksum生成をした上で

delegated -P 80 MOUNT=”/journal/* blogURI/*” PERMIT=”http:*:*”

としてあげる必要があった。

おまけ

無事動作したので、一区切りついたということでお祝いに寿司を食べてきた。

さらっと書いているが、結構大変な作業でトラブル続きだったことを報告しておく。