UNIX Cafe | 第75回
Xserverで起きたトラブルと、正しい解決方法
今回は、Xserverを利用している環境で、VPNを使ったときに実際に起きたトラブルの原因と解決方法を、順を追って整理していきます。
VPNを使っていると、
WordPressの管理画面にログインできなくなることがあります。
VPNを切るとログインできるのに、
VPNを入れると突然エラーになる。
Google Analytics に「固定IPを設定して、正確にアクセス解析がしたいのに、どうして…？」
今回は、
Xserver＋VPN＋WordPress という組み合わせで実際に起きたトラブルを通して、
- なぜログインできなくなったのか
- なぜ
.htaccessの設定が効かなかったのか - なぜ Xserver の FAQ にあるコードは “効いたように見えた” のか
- そして、どの方法が正解だったのか
を、順番に紹介します。
今回、起きた問題｜VPNを使うと管理画面に入れない
Google Analytics の計測結果から自分のアクセスを除外するために、新規でVPNサービスに申込みを済ませて、MacにVPNのIPアドレスを設定。
WordPressにアクセスすると、管理画面にログインできない状況になりました。
- VPNをOFFにすると、WordPressに普通にログインできる
- VPNをONにすると、管理画面に入れない
- サイトの表示自体は問題ない
エラーは 403 やアクセス制限に関するもの。
「IP制限かな？」
そう思って、まずは .htaccess の設定を変更します。
最初に試したこと｜.htaccessでIP制限
WordPressの管理画面を守る方法として、
よく知られているのが IP 制限です。
そこで、特定のIPだけを許可する方法を考えてみます。たとえば、次のような設定です。
<Files "wp-login.php">
<RequireAll>
Require ip VPNのIP
</RequireAll>
</Files>
考え方としては正しそうです。
「VPNのIPだけ許可すればいい」ですが、結果は403エラーになりました。
ここで、「何かがおかしい」と感じ始めます。
XserverのFAQに書かれていたコード
調べて見ると、Xserverの公式FAQに、次のコードが紹介されていました。
SetEnvIf Request_URI ".*" AllowWPLoginFromCloudJP先ほどのコードを消して、
新たに、このコードを .htaccess に追加すると、
VPNをONにしたままでも、管理画面にログインすることができました。
ここで疑問が生まれます。
IPを見ていないはずのコードなのに、なぜ効くのか？
いったい、どこでアクセスが制御されているのか？
SetEnvIfは「許可設定」ではない
まず大切なのは、
次のコードが アクセスを許可する設定ではない という点です。
SetEnvIf Request_URI ".*" AllowWPLoginFromCloudJP- 管理画面へのアクセスを許可する
- IP制限を解除する
といった処理を、Apache自身が行っているわけではありません。
この設定がしていることは、
Apacheの環境変数を1つ立てているだけです。
何が起きているのか (^^;?
SetEnvIf は、「ある条件に一致したら、目印（フラグ）を付けておく」ための命令です。
今回の場合、
Request_URI ".*"→ すべてのリクエストに一致AllowWPLoginFromCloudJP→ そのリクエストに、この名前のフラグを付ける
という意味になります。
つまり、すべてのアクセスに対して
「AllowWPLoginFromCloudJP」という合図を付けている だけです。
この時点では、「通す」「止める」といった判断は、
まだ行われていません。
なぜ多くのIPは動的なのか｜管理で問題になる理由
ここで、少しだけ前提の話をします。
インターネットに接続するとき、 私たちは必ず IPアドレス という番号を使っています。
このIPアドレスには、 固定IP と 動的IP の2種類があります。
そして実は、 世の中で使われているIPアドレスのほとんどは、動的IP です。
動的IPは、接続のたびにIPアドレスが変わります。 自宅のインターネットや
スマートフォンの通信では、 この仕組みが当たり前に使われています。
ふだんの利用では、IPが変わっても困ることはありません。
動画を見たり、調べものをしたりするだけなら、 動的IPで十分です。
しかし、サーバー管理やWordPressの運用では話が変わります。
IP制限やホワイトリスト設定のように、 「このIPだけを許可する」 仕組みでは、
IPが変わる動的IPは扱いづらくなります。
そのため、Google Analyticsでアクセス解析を行ったり、WordPressの管理画面への
アクセスを安定させたい場合は、 固定IP を使うという選択肢が必要になってきます。
それでは次に、この「IPの性質」を踏まえたうえで、
実際に、どこでアクセスが制御されていたのかを見ていきます。
本当の原因｜Xserverの「WordPressセキュリティ設定」
実際に Apache 側の制御を変更しても挙動が変わらなかったことから、wp-login.php に到達する前段で、Xserver独自の WordPress セキュリティ設定がアクセスを制御していることを確認できました。
今回アクセスを止めていたのは、
- WAF（ModSecurity）のような完全な前段ブロックではなく、
- Xserver独自の「WordPressセキュリティ設定」でした。
この機能は、
- 国内IPであっても
- クラウド・VPS・VPN由来と判定されたIP
を、WordPress管理画面への攻撃が多いIPとして制限します。
そして重要なのは、この制限ロジックが、
Apacheの環境変数（SetEnvIf）を参照している
という点です。
実際の処理の流れ（今回のケース）
- VPN
- Apache（.htaccess / SetEnvIf）
- Xserver WordPressセキュリティ設定
- WordPress
つまり、
- Apacheで
AllowWPLoginFromCloudJPが立っていると - Xserver側が「このアクセスはクラウドIP制限の例外」と判断し、
- 管理画面へのアクセスを通す
という仕組みです。
そのため、FAQのコードを入れると ログインできるようになりました。
注意点｜SetEnvIf は最終的な解決策ではない
SetEnvIf Request_URI ".*" AllowWPLoginFromCloudJPこの書き方には、大きな注意点があります。
- すべてのURI
- すべてのアクセス
に対して、例外フラグを常にONにするため、国内クラウドIP制限を、事実上、無効化した状態になります。
これは、
- 原因切り分け
- 一時的な回避
としては有効ですが、長期運用には向いていません。
正しい対処法｜Xserver公式のホワイトリスト設定を使う
最終的に行ったのは、
Xserverの管理画面から、VPNのIPアドレスを「許可リスト」に登録する方法です。
これは、Xserverが用意している正式な設定画面を使う方法です。
実際に行った設定手順
Xserverのサーバーパネルで、次の順に進みました。
- 「Xserver・サーバーパネル」 にログイン
- 「WordPressセキュリティ設定」 を開く
- 「ドメイン名」を選択
- 「国外アクセス制限設定」 を選択
- 「ダッシュボードアクセス制限」→「変更」 をクリック
- 「ホワイトリストIPアドレス」 に VPNの出口IPアドレスを追加
※ VPNの出口IPアドレスは（VPNをONにしたときに表示されるIP）のことです。
この方法では、
- 許可するIPが明確
- 意図しないアクセスを通さない
- Xserverが想定している使い方
という点で、最も安全です。
この後は、VPNをONにしたままでも、
問題なく管理画面にログインできるようになりました。
実際、こうした設定を安定して行うには、
固定IPが使えるVPNサービスを選ぶのがとても大切です。
私が今回使ったのが、「ロリポップ！固定IPアクセス」です。
今回の学び｜迷わないためのポイントまとめ
今回のトラブルで分かったことをまとめます。
.htaccessは万能ではない- Xserverには Apacheと連携する独自制御がある
- FAQのコードは「裏技的な回避策」にすぎない
- 正規ルートは 管理画面でのホワイトリスト設定
- VPNは、固定IPを使うための良い選択である
だからこそ、サーバー側の防御と、自分のアクセスをどう両立させるか
を理解しておくことが大切だと感じました。
まとめ｜VPNでログインできないときの確認ポイント
VPNを使うとWordPressにログインできないときは、
.htaccessを疑う前に- WordPressを疑う前に
まず、Xserverの「WordPressセキュリティ設定」を確認してみてください。
SetEnvIf のコードが効いた理由を理解した上で、
安全な設定（ホワイトリスト登録）に落とし込むことが大切です。
今回の経験が、同じところで立ち止まっている方の
ヒントになれば幸いです。
さらに学びたいあなたへ
📘 用途ごとに選ぶ Linux のおすすめ本
