Chienomi

不安定なホスト(非固定IPアドレス, 非常時稼働)をサーバーにする

technique

  • TOP
  • Old Archives
  • 不安定なホスト(非固定IPアドレス, 非常時稼働)をサーバーにする

需要があるらしいので、この話。

不安定なホスト(非固定IPアドレス―浮動IPアドレス, ステートフルIPアドレス, あるいは間違っているけれど可変IPアドレス― または 非常時稼働システム)をサーバーにする、というテーマで、 方法はたくさんあるのだが、私の結論は「商業レベルでやることではない」である。

待ち受ける

DDNS

最も普通の方法だが、実際にはかなり制約が多い。

SFPレコードは効かないし、DNSレコードは反映をコントロールできない1ので逆引きが効かなかったりでサーバーとしては結構痛いことになる。

リバースフォワーディング

これはかなり簡単な方法で、例えば次のようにする。

# ssh -g -R 80:localhost:80 serverhost

これによってインターネットから安定して接続できるホストに代理ホストとして公開してもらう。

不安定なホストの非稼働時は代理ホストが応答する。

フロントエンドプロキシ

リバースフォワーディングと同様に代理ホストに公開してもらうのだが、不安定なホストに通信を転送させるのではなく、中継させるという方法。

まずなんらかの方法で代理ホストと不安定なホストを接続する。 例えばVPNで接続する。

# pppd updetach noauth silent nodeflate pty "ssh root@remote-gw /usr/sbin/pppd nodetach notty noauth" ipparam vpn 10.0.8.1:10.0.8.2

あるいはSSHによる転送を行う。

$ ssh -R 8080:localhost:80

そして、代理ホスト上でリバースプロキシを動作させる。例えばSquidやNginxをプロキシとして、ローカルネットワークホストとして、あるいはローカルホストの別ポートとして転送する。

VPNで接続している場合、代理ホストからは不安定なホストは不安定なグローバルIPアドレスではなくローカルなIPアドレス10.0.8.1として認識される。

不安定なホストの非稼働時は代理ホストが応答する。

逆接続モデル

利用可能なサーバーが限定されてしまうが、サーバーからクライアントに接続するモデルがとれるのであれば、不安定なホストであることはあまり問題にならない。 あるいはサーバーリレーするタイプ(送信専用メールサーバーなど)でも機能する。

VPNで接続する

インターネット公開しているのでないのならば、代理ホストを経由するなどしてVPNで接続し、ローカルなアドレスを代わりに使うという方法が効く。

非IP

「IPアドレスが固定でない」ことはIPアドレスを用いる場合にのみ問題として発生する。 だったらIP以外で通信すれば良い。

ただし、この場合はほとんどローカルなIPアドレスで運用する方法も適用できる(VPNで接続するなど)ことになるし、 リンクローカルな通信であることがほとんどだから、これを転送するハードルを考えるとあまり易しくはない。

例えばセキュリティの都合上でIP接続を許可していないAoEサーバー、なんていうのはアリだ。

Zeroconf

リンクローカルでIPアドレスが固定でないことを考慮しなければならないケースはあまり見当たらないが、 リンクローカルなのであればZeroconfが使える。

IPアドレス制限されたホストに接続する

レンジで許可する

ステートフルに割り振られるIPアドレスのレンジが十分に制限されているのであれば範囲で許可すれば良い。

ゲートウェイ経由

固定IPアドレスを持つホストを経由して接続する。

SSHならば割と簡単にできる。

$ ssh -L 10000:destination.example.com:10000 proxyhost

VPNで代理ホストを経由しても良い。

別の方法で接続する

例えばSSHやVPNなど特定のポートだけIPアドレス制限の対象外とした上で、これらのセキュアトンネルを通じて接続する。

MySQLサーバー等、認証が強力でないサービスのためにIPアドレス制限がなされているのであれば、SSHのように認証が強力な方法についてはIPアドレス制限から除外し、これを経由することを許す、というわけである。

許可されているホストに依頼する

ゲートウェイ接続はできないまでも融通の効くホストで接続が許可されているホストがあるのであれば、これをプロキシとして接続する。

このような場合普通はアプリケーションプロキシとして使うか、SOCKSプロキシとして使うものだ。 このプロキシに対する接続に認証を求めるべきで、異なる方法で安全性を担保させるわけである。

ちなみに、以前紹介したSSHフォワーディングの場合

  1. ローカルなポートフォワーディングにより代理ホストから不安定なホストに通信を中継するようにする。 (これ自体は公開されていない)
  2. プロキシコマンドとして外部ホストから代理ホストに対して接続を行う
  3. これによって確立された経路を使って代理ホストのlocalhost(lo)に対してSSHを通す (これがダイナミックポートフォワーディングによって不安定なホストに転送される)

という方法で、計3本のトンネルが通されることになる。


  1. 「TTLに従う」と信じているなら、ちょっとハッピーすぎる。↩︎