【入門編】pgAdmin 4のSSHトンネル(Port Forwarding)接続で「Network Error」が出る時の原因とファイアウォール越えの設定手順 – データベース・API管理活用バイブル

こんにちは!データベースとインフラの裏側を覗くのが大好きな先輩エンジニアです。

今回は、開発現場で避けて通れない「セキュアなデータベース接続」の王道、「pgAdmin 4のSSHトンネル(ポートフォワーディング)機能」についてお話しします。

本番環境やセキュアなVPC(仮想プライベートクラウド)内にあるPostgreSQLに接続する際、「踏み台サーバー(踏み台EC2など)」を経由しなければならない場面は多々ありますよね。そんなとき、pgAdmin 4のビルトインSSHトンネル機能を使えば、わざわざターミナルで `ssh -L` コマンドを叩いてポートフォワーディングを手動で張る手間が消え、GUIだけで完結するのでめちゃくちゃスマートになります。

……しかし!この機能、初心者が最初に挑戦すると9割の確率で「Network Error」にぶつかります。

「設定は合っているはずなのに、なぜ繋がらないんだ……?」と深夜のオフィスで頭を抱えた経験、ありませんか?
今回は、その「Network Error」の正体を完全に暴き、ファイアウォールをスマートに越えて一発で接続を成功させるための極限の知見を、優しく丁寧に伝授します。これをマスターすれば、毎日のインフラ周りの作業が劇的に楽になりますよ!

—

1. なぜ「Network Error」が出るのか?(根本原因の理解)

pgAdmin 4からSSHトンネルを経由してPostgreSQLに接続する仕組みは、下図のようになっています。

[ あなたのPC (pgAdmin 4) ]
│
▼ (SSH接続: ポート22)
[ 踏み台サーバー (Bastion Host) ]
│
▼ (ローカルフォワード: ポート5432)
[ PostgreSQL データベースサーバー ]

この通信路のどこかで「通せんぼ」を食らうと、pgAdminは冷酷に 「Network Error」 とだけ吐き出します。主な原因は以下の3つに集約されます。

1. 秘密鍵(Private Key)のパーミッションが緩すぎて、SSHクライアント(Paramiko)に拒絶されている
2. SSHのタイムアウト(Idle Timeout)により、ファイアウォールやルーターにセッションを静かに切断されている
3. 踏み台サーバーのファイアウォール(iptables / firewalld / security group)でブロックされている

一つずつ、確実にクリアしていきましょう。

—

2. 基礎セットアップ:踏み台経由接続の正しいレシピ

まずは、pgAdmin 4の正しい設定手順を確認します。ここを間違えると絶対に繋がりません。

ステップA:サーバー定義の基本タブ(General)

  • Name: 任意の名前(例: `Production-DB`)

ステップB:接続タブ(Connection)

ここでの罠は 「データベースサーバーのIPアドレス」 です。

  • Host name/address: 踏み台から見たPostgreSQLの内部IP(またはホスト名) を入力します。あなたのPCから見たIPではありません!ここを間違える初心者が本当に多いです。
  • Port: `5432`
  • Maintenance database: `postgres`(または接続するDB名)
  • Username / Password: PostgreSQLのユーザー情報

ステップC:SSHトンネルタブ(SSH Tunnel)★ここが最重要

  • [✔] Use SSH tunneling にチェックを入れます。
  • Tunnel host: 踏み台サーバーのパブリックIPまたはドメイン
  • Tunnel port: `22`(通常はSSHのポート)
  • Username: 踏み台サーバーのSSHユーザー名(例: `ec2-user`, `ubuntu`)
  • Authentication: `Password` または `Identity file (秘密鍵)`

※本番環境なら絶対に鍵認証(Identity file)を使いましょう。

—

3. 現場で役立つ!3大トラブルシューティングと対策

ここからが本題です。「Network Error」を粉砕するための具体的なテクニックを解説します。

トラブル1:秘密鍵のパーミッションエラー(Permission denied / 鍵が読み込めない)

特にWindowsからMac/Linuxへ移行したエンジニアや、その逆のパターンで最も多いのがこれです。
pgAdmin 4の内部で使われているSSHライブラリ(PythonのParamiko)は、秘密鍵のパーミッションが「他のユーザーからも読める状態(例: 777や644)」になっていると、セキュリティ上の理由から頑なに読み込みを拒否します。

【対策】パーミッションを厳格に絞る

  • macOS / Linux の場合:

ターミナルを開き、秘密鍵の権限を `600`(自分だけが読み書きできる状態)に厳しく制限します。

chmod 600 ~/.ssh/id_rsa_bastion

  • Windowsの場合:

1. 秘密鍵ファイルを右クリック >「プロパティ」>「セキュリティ」タブを開く。
2. 「詳細設定」をクリック。
3. 自分以外のすべてのユーザー(SYSTEMやAdministratorsを除く、継承されたユーザー権限など)を削除し、アクセス権を自分(Owner)のみにします。

—

トラブル2:ファイアウォールと「Silent Timeout(無言の切断)」

「接続ボタンを押してしばらく固まったあと、Network Errorが出る」という場合、これはファイアウォールやルーターが、一定時間通信がないSSHセッションを勝手に切断(TCP Timeout)していることが原因です。

これを防ぐためには、「一定間隔で死活信号(Keep-Alive)を送り、接続を維持する」設定を施す必要があります。

残念ながら、pgAdmin 4のGUI画面上にはSSHのKeep-Aliveを詳細に設定する入力欄がありません。しかし、ユーザーのホームディレクトリにある設定ファイルを直接書き換えることで回避できます。

【対策】SSHクライアントの設定ファイル(`~/.ssh/config`)を書く

あなたのPCのターミナル(WindowsならPowerShellやWSL)で、SSHのグローバル設定を行います。pgAdminのSSHライブラリもこの設定を参照してくれます。

~/.ssh/config または C:\Users\ユーザー名\.ssh\config に追記

Host bastion-server-alias
HostName 192.0.2.1 # 踏み台のIPアドレス
User ec2-user # 踏み台のSSHユーザー
IdentityFile ~/.ssh/id_rsa_bastion # 秘密鍵のパス

# 【最重要】30秒ごとにパケットを送り、接続の切断を防ぐ
ServerAliveInterval 30
ServerAliveCountMax 3

この設定を入れておくだけで、ネットワークの背後にある厳格なファイアウォールを味方につけ、安定したセッションを維持できるようになります。

—

トラブル3:踏み台からDBサーバーへのセキュリティグループの穴あけ忘れ

pgAdmin 4と踏み台の接続が成功したのにNetwork Errorが出る場合、犯人は 「踏み台からPostgreSQLサーバーへの通信」 です。

AWSなどのクラウド環境では、セキュリティグループ(SG)やファイアウォール(ufwなど)で厳密に通信が制限されています。

【対策】インバウンドルールの確認

  • PostgreSQLサーバー側のセキュリティグループ:
  • 許可するプロトコル: `TCP`
  • ポート範囲: `5432`
  • ソース(送信元): 「踏み台サーバーのプライベートIP」または「踏み台のセキュリティグループID」を指定する。

※自分のPCから直接DBサーバーの5432ポートにアクセスできてはいけません。「踏み台を経由して初めて通る」状態になっていることが、セキュアなアーキテクチャの基本です。

—

4. 精度高い「HelloWorld」的動作確認クエリ

さあ、無事に設定が完了したら、pgAdmin 4の「Query Tool」を開いて、ファイアウォールとSSHトンネルが正常に開通しているかを証明するための「Hello World」ならぬ「System Health Checkクエリ」を流してみましょう。

以下のSQLを実行してみてください。

— 接続が正常にトンネリングされているかと、現在のセッション情報を確認する
SELECT
current_database() AS connected_db,
current_user AS db_user,
inet_server_addr() AS db_server_internal_ip,
version() AS pg_version,
now() AS server_current_time;

【期待される結果】
エラーが出ずに、データベース名、ユーザー名、PostgreSQLのバージョン、そして踏み台から見たDBサーバーの内部IP(プライベートIP)が綺麗に表示されれば、SSHトンネル経由のセキュア接続は大成功です!

—

先輩からのアドバイス

データベースとインフラストラクチャを繋ぐトンネル技術は、慣れるまでは少し黒魔術のように感じるかもしれません。「Network Error」というそっけないエラーメッセージに心を折られそうになることもあります。

しかし、今回紹介した「パーミッションの厳格化」「SSH ConfigでのKeep-Alive設定」「セキュリティグループの正しい理解」という3つのポイントさえ押さえておけば、どんなに厳重な要塞環境(ファイアウォール)であっても、一発で華麗に突破できるようになります。

毎日のデータベース開発が、より安全で、ストレスフリーなものになりますように。それでは、良質なコードと堅牢なインフラライフを!

タイトルとURLをコピーしました