自前プロキシIPのサーバー側を準備する実践的な順序です。まずSSH接続を確認し、ポート変更と鍵認証への移行、基本的なハードニング、プロキシサービスの導入とポート開放を行い、最後にクライアントから接続して検証します。
クラウドサーバーを購入してプロキシとして使う場合、つまずく原因は単純な接続性そのものではなく、サーバー側の準備順序であることがほとんどです。順序が正しければクライアントはたいてい一度で接続できますが、順序が乱れると何度もターミナルへ戻って設定を直すことになります。
ここではサーバー側だけを扱います。初回ログイン、入口の引き締め、プロキシサービスの起動、ポート開放、クライアント接続、そして接続できない場合の段階的な切り分けまでを説明します。
初回ログインでは、まず入口を確認する
インスタンスを作成したら、最初はプロバイダーの管理コンソールにあるWebターミナルからログインし、いきなりローカルツールだけに頼らないようにします。この段階の目的は、サーバーが稼働していてネットワークに到達できることを確認するだけです。
ログインしたら sudo -i を実行して Enter を押し、root に切り替えます。プロンプトが $ から # に変われば権限昇格は成功です。以降の操作はこの権限で行います。
その場で4つの情報を控えておきます。公開IP、ログインユーザー名（Linuxでは既定で root）、パスワード、SSHポート（既定で22）です。クライアント接続にはこの4項目が必要で、どれか1つでも欠けると接続できません。
既定ポートを変更し、次に鍵認証へ切り替える
ポート22は毎日無数にスキャンされ、自動化されたログイン試行も日常的です。ポート変更だけでサーバー自体が強固になるわけではありませんが、自動化されたノイズの大半を除外できます。
変更箇所は /etc/ssh/sshd_config です。vi で開き、i を押して編集モードに入り、PermitRootLogin と PasswordAuthentication の行を yes に変更します。次に Esc を押し、:wq と入力して保存して終了します。プロバイダーが鍵ログインに対応している場合は、ローカルの公開鍵をサーバーの authorized_keys に追加し、その後 PasswordAuthentication を no にして鍵だけを許可する方法がより堅牢です。
設定変更後に現在のセッションをすぐ閉じないでください。 先に別のターミナルウィンドウを開き、新しいポートと新しい認証方法で一度ログインし、入れることを確認してから古いウィンドウを閉じます。設定を誤ると自分を締め出してしまい、プロバイダーのコンソールから復旧するしかなくなります。
SSHポートは Port の行で変更します。変更後は設定を反映するためSSHサービスを再起動します。DebianやUbuntu系では /etc/init.d/ssh restart を実行できます。
初日に基本的なハードニングを済ませる
ポート変更と鍵認証に加え、初日に済ませておきたい小さな作業が2つあります。1つ目は passwd root で root に十分長いランダムなパスワードを設定し、推測しやすい組み合わせを使わないことです。2つ目は不要なサービスとポートを停止することです。サーバー上で動くものが少ないほど攻撃対象領域は小さくなり、システムファイアウォールでは本当に必要なポートだけを許可します。
このサーバーを長期にわたり数か所の固定した送信元だけから使うのであれば、セキュリティグループで送信元アドレスをそれらに限定します。インターネット全体へ開放するより大幅に安全です。
プロキシサービスを導入し、認証を設定する
サーバー側の初期化が終わったら、プロキシ自体を設定します。
1つの方法はSSHトンネルをそのまま利用することです。サーバーに追加インストールは不要で、クライアントがシステム標準のSSHサービスを転送に使い、認証情報もサーバーのものを利用します。手軽ですが性能は平均的で、同時接続が増えると厳しくなるため、一時利用やアカウント数が少ない場合に向いています。
もう1つは専用のプロキシサービスをサーバーへインストールする方法です。通常は1つのインストールコマンドで導入でき、その後に認証方式と待受ポートを自分で設定します。自動起動を有効にしておかないと、サーバーを一度再起動しただけでプロキシも停止します。
認証は安全性が高くなる順に3段階で考えられます。ユーザー名とパスワードは最も簡単ですが、漏えいすればプロキシを渡したのと同じです。パスワードに送信元IPの許可リストを組み合わせれば日常利用には十分です。鍵または証明書による認証が最も堅牢で、設定は少し手間ですが長期運用するアカウントには有効です。
ポートは2か所でそれぞれ開放する
ここが最も詰まりやすいポイントです。プロキシサービスの待受ポートは、システムファイアウォールとプロバイダーのセキュリティグループの両方で開放する必要があります。両者は独立しているため、片方だけを開けても接続できません。
もう1つ見落としやすいのがサービスの待受アドレスです。一部のサービスは既定で 127.0.0.1 にしかバインドしません。サーバー上のローカルテストは通るのに外部から接続できない場合、原因はこれであることがよくあります。待受アドレスをサーバーのプライベートアドレスまたは 0.0.0.0 に変更します。
ローカルクライアントから接続する
環境管理ツールで新しい環境を作成し、実際に使うプロキシ種別を選びます。SSHトンネルを使う場合、アドレスにはサーバーの公開IP、ポートにはSSHポート、ユーザー名とパスワードにはサーバーの認証情報を入力します。入力後に接続テストを実行します。
テストに成功しても、通信経路が通っていることしか確認できません。環境を開き、さらに3点を確認します。出口IPがサーバーの公開IPになっているか、DNSもプロキシを経由しているかを確認します。DNSがローカル解決のままだと、出口IPと一致しない地域情報が露出する可能性があります。さらに、タイムゾーンと言語が出口地域と一致しているかも確認します。3項目すべてを満たして初めて、その環境を利用可能と判断できます。
アカウントが増えてきたら、複数のアカウントが同じ環境を共有しないよう、環境と出口の対応関係を固定します。PurpleMarkのようなツールではアカウントごとに個別の出口を割り当てられ、手作業で対応表を管理するより安定します。
接続できない場合は外側から内側へ確認する
最も外側から確認します。セキュリティグループで許可されているか、システムファイアウォールで許可されているかを確認し、両方に問題がないことを確かめてから次へ進みます。
次にサービス自体を確認します。プロセスはまだ動いているか、特にサーバー再起動後は要確認です。また、待受アドレスがローカルだけにバインドされていないかも見ます。
さらに認証層を確認します。ユーザー名やパスワードが間違っていないか、鍵ファイルの権限が広すぎないかを確認します。権限が不適切だとSSHDは鍵を直接拒否します。最後にクライアント側を確認し、入力したアドレスが公開IPなのか、誤ってプライベートIPを入れていないかを見ます。ここは特に混同しやすい箇所です。
この順序で進めれば、サービスを何度も再インストールするのではなく、通常は2〜3回の確認で問題のある層を特定できます。
まとめ
サーバー側の準備は30分もかかりませんが、その後数か月の運用が楽になるかどうかを左右します。入口を引き締め、必要なポートを正しく開放し、認証を明確に設定しておけば、残るのは日常的なメンテナンスだけです。
