Kubernetes 上で運用している WordPress のサイトヘルスで、wordpress.org に接続できないというメッセージが出ることがあります。プラグイン更新、テーマ更新、翻訳ファイル取得、WordPress 本体更新、サイトヘルスなど、WordPress は外部の wordpress.org へ接続する場面が多いため、この経路が不安定だと運用に影響します。
この記事では、当時発生した「Pod から wordpress.org へ接続できたりできなかったりする」事象を、WordPress の外向き通信障害として整理します。最終的には、さくらの VPS 側のファイアウォールを無効化することで解消しました。
かなり限定的な環境の話ではありますが、切り分けの観点は一般化できます。重要なのは、WordPress、Pod、Kubernetes ノード、VPN / PBR、MTU / MSS、DNS、外部ファイアウォールを分けて確認することです。
書籍
WordPress 仕事の現場でサッと使える！デザイン教科書 [WordPress 6.x対応版] 改訂第3版
WordPress のサイト構築、テーマ、カスタマイズ、運用項目を確認したい場合の参考書籍です。価格や在庫、WordPress の最新仕様との差分はリンク先や公式ドキュメントで確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
書籍
DNS がよくわかる教科書 第 2 版
DNS の基本、名前解決、権威 DNS、キャッシュ DNS、DNSSEC などを体系的に確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
書籍
マスタリング TCP/IP 入門編 第6版
TCP/IP、Ethernet、VLAN、ルーティングなど、ネットワークの基礎を体系的に確認したい場合の参考書籍です。価格や在庫はリンク先で確認してください。
Amazon で見るこのリンクは Amazon アソシエイトリンクです。
関連する記事
WordPress の構築、Kubernetes 運用、メール送信、REST API、WAF の記事と合わせると、WordPress 運用で見るべき経路が整理しやすくなります。
- Ubuntu 22.04 WordPress – Apache / PHP / MariaDB で CMS を構築する
- WordPress を Kubernetes で運用する構成
- WordPress のメール送信が遅い原因 – sendmail、Postfix、名前解決を切り分ける
- WordPress の「返答が正しい JSON レスポンスではありません」を切り分ける
- WordPress 更新後に ModSecurity が偽陽性判定する原因と調整方針
発生した事象
Kubernetes 上に構築した WordPress のサイトヘルスで、wordpress.org に接続できないというメッセージが表示されました。
WordPress の Pod から curl で wordpress.org へ連続してアクセスすると、接続できる時とできない時がありました。一方で、WordPress の Pod が稼働している Kubernetes ノードから同じように確認すると、問題はありませんでした。
| 確認場所 | 結果 |
|---|---|
| WordPress Pod | wordpress.org へ接続できる時とできない時がある。 |
| Kubernetes ノード | 連続して curl しても問題なし。 |
| 他サイト | www.google.co.jp や www.yahoo.co.jp では問題なし。 |
| wordpress.org | 特定条件でのみ不安定。 |
この時点で、単純なインターネット接続断ではなく、Pod から外へ出る経路、または wordpress.org への通信条件に依存した問題だと考えられます。
WordPress が wordpress.org に接続する場面
wordpress.org への接続は、管理画面で明示的に操作した時だけ発生するわけではありません。WordPress の運用では、次のような場面で外向き通信が必要になります。
- WordPress 本体の更新確認。
- プラグインやテーマの更新確認。
- 翻訳ファイルの取得。
- サイトヘルスの外部接続確認。
- プラグインやテーマのインストール。
そのため、wordpress.org への接続が不安定だと、管理画面では更新確認が失敗したり、サイトヘルスで警告が出たりします。WordPress の画面だけを見るとアプリケーションの問題に見えますが、実際にはネットワーク経路の問題であることがあります。
環境の特徴
当時の環境では、自宅環境とさくらの VPS を VyOS で常時 VPN 接続していました。WordPress が稼働する Kubernetes ノードのセグメントは PBR、つまり Policy Based Routing によりデフォルトルートを変更し、さくらの VPS 経由でインターネットへ出ていました。
VPN は OpenVPN を使用し、その上に IP6GRE を重ねていました。これは OSPF を使用するためです。このような構成では、経路、MTU、MSS、NAT、ファイアウォール、CNI のすべてが外向き通信に影響する可能性があります。
切り分けるレイヤー
| レイヤー | 確認すること |
|---|---|
| WordPress | サイトヘルスや更新確認で何が失敗しているか。 |
| Pod | Pod 内から curl、名前解決、IPv4 / IPv6 の到達性を確認する。 |
| Kubernetes ノード | ノードから同じ宛先へ接続できるか確認する。 |
| CNI | Pod から外へ出る時の NAT、MTU、経路を確認する。 |
| VPN / PBR | デフォルトルート、ポリシールーティング、トンネル経路を確認する。 |
| 外部ファイアウォール | VPS 側やクラウド側のフィルタリングが関与していないか確認する。 |
Pod から確認する
まず、WordPress Pod から wordpress.org へ接続できるかを確認します。成功と失敗が混在する場合は、1 回だけの確認ではなく、連続して試すことが重要です。
kubectl -n wordpress-ext-system get pod -o wide
kubectl -n wordpress-ext-system exec -it deploy/wordpress -- sh
for i in $(seq 1 10); do
date
curl -I --connect-timeout 5 https://wordpress.org/
donePod 内に curl がない場合は、一時的なデバッグ Pod を使います。重要なのは、WordPress と同じ Namespace、同じノード、同じネットワーク条件で確認することです。
kubectl -n wordpress-ext-system run net-debug --rm -it --image=curlimages/curl -- sh
for i in $(seq 1 10); do
date
curl -I --connect-timeout 5 https://wordpress.org/
doneノードから確認する
次に、WordPress Pod が稼働している Kubernetes ノードから同じ宛先へ接続します。Pod では失敗し、ノードでは成功する場合、Pod から外へ出る経路、CNI、NAT、MTU、外部ファイアウォールとの相性を疑います。
curl -I --connect-timeout 5 https://wordpress.org/
for i in $(seq 1 10); do
date
curl -I --connect-timeout 5 https://wordpress.org/
doneDNS と IPv4 / IPv6 を分ける
wordpress.org だけで問題が起きる場合、DNS、IPv4 / IPv6、宛先側の CDN、経路の違いを分けて確認します。
getent hosts wordpress.org
nslookup wordpress.org
curl -4 -I --connect-timeout 5 https://wordpress.org/
curl -6 -I --connect-timeout 5 https://wordpress.org/IPv4 では成功するが IPv6 では失敗する、またはその逆であれば、DNS ではなく IP ファミリー別の経路問題として見ます。DualStack 環境では、この切り分けを省くと遠回りになります。
MTU / MSS を疑ったが違った
最初に疑ったのは、OpenVPN と IP6GRE を重ねた環境における MTU / MSS でした。MTU / MSS は、VPN、GRE、IPsec、Kubernetes CNI をまたぐ通信で分かりにくいトラブルを起こすことがあります。
このため、MTU / MSS をさらに小さくしたり、複数ポイントで調整したりしましたが、今回の事象には変化がありませんでした。つまり、疑う順番としては妥当でしたが、原因ではありませんでした。
ip route
ip link
tracepath wordpress.org
ping -M do -s 1200 wordpress.orgMTU 問題は疑う価値がありますが、すべての不安定な通信を MTU に寄せると切り分けを誤ります。Pod、ノード、経路、外部ファイアウォールの差分を見ながら判断します。
最終的な原因
最終的には、さくらの VPS 側で設定していた VM 単位のファイアウォールを完全に無効化することで解消しました。
このファイアウォールは簡単に設定できる反面、詳細なログを確認する手段が限られており、トラブル時には無効化による切り分けが現実的でした。今回のケースでは、常にブロックされるわけではなく、接続できる場合もあったため、何らかの条件や閾値で DROP されていた可能性があります。
確証はありませんが、Pod から出る通信、CNI、NAT、経路、またはパケットの見え方が、外部ファイアウォール側の判定条件に引っかかった可能性があります。少なくとも、ノードからは問題なく、Pod からだけ不安定だった点は重要です。
クラウド側ファイアウォールを見るときの注意
クラウドや VPS のファイアウォールは便利ですが、詳細なログが見られない場合、障害時の切り分けが難しくなります。特に、INPUT だけでなく OUTPUT 側やステートフルな判定が関与する場合、利用者側からは挙動が見えにくいです。
- ファイアウォールを無効化して改善するか確認する。
- 無効化した場合は、代替の防御層があるか確認する。
- VyOS や自前の firewall でログを取れるなら、そちらで制御する。
- VPS 側の簡易ファイアウォールと自前 firewall を二重に使う場合、責務を明確にする。
- ログが見えない防御層は、障害時に被疑箇所から外しにくい。
今回の環境では VyOS 側でファイアウォールを設定していたため、さくらの VPS 側のファイアウォールを切っても防御方針としては成立していました。防御層を減らす場合は、どこで代替しているのかを明確にする必要があります。
WordPress 側で確認すること
WordPress 側では、サイトヘルスの表示だけで判断せず、WP-CLI やコンテナ内 curl で外向き通信を確認します。WP-CLI が使える場合は、更新確認や HTTP API 周辺の状況も確認できます。
wp core check-update
wp plugin list
wp theme list
wp transient delete --allただし、WP-CLI が成功しても、実際の Pod、Web コンテナ、PHP 実行環境が同じ経路を使っているとは限りません。確認は、問題が起きている実行環境から行います。
まとめ
WordPress が wordpress.org に接続できない場合、WordPress 本体やプラグインだけを見ると原因を見誤ります。特に Kubernetes 上の WordPress では、Pod、ノード、CNI、VPN、PBR、MTU / MSS、DNS、外部ファイアウォールまで含めて、外向き通信の経路として確認する必要があります。
今回の事象では、Pod から wordpress.org への通信だけが不安定で、ノードからは問題ありませんでした。MTU / MSS も疑いましたが、最終的には VPS 側ファイアウォールを無効化することで解消しました。
限定的な環境の話ではありますが、切り分けとしてはかなり重要です。WordPress のサイトヘルスに出る外部接続エラーは、WordPress の画面上の問題ではなく、ネットワーク経路全体の問題として見るべきです。
Related posts:
CentOS 8 で WordPress を構築した記録 – 現在は Ubuntu / Kubernetes 構成へ読み替える
WordPress の予約投稿が 9 時間ずれる原因 – Docker / Kubernetes 環境のタイムゾーンを確認する
コンテナ上の WordPress からメールが送信できない原因 – SMTP / sendmail / Postfix を切り分ける
Ubuntu 22.04 WordPress – Apache / PHP / MariaDB で CMS を構築する
WordPress のショートコード運用を見直す – 経過日数表示を例に本文と機能を分離する
WordPress を Kubernetes で運用する構成 – コンテナ、永続化、DB、メール、外部公開を分けて考える
WordPress の「返答が正しい JSON レスポンスではありません」を切り分ける
WordPress のメール送信が遅い原因 – sendmail、Postfix、名前解決を切り分ける
WordPress ブロックエディタを使う理由 – 記事構造と再利用性を高める
WordPress のスパムコメント対策 – コメント欄を開くリスクと運用設計
WordPress のサイトマップが生成されない原因 – パーマリンク設定と URL 設計を見直す
WordPress 更新後に ModSecurity が偽陽性判定する原因と調整方針