VPN 経由の MySQL localhost：それでもローカルプロセスを指す

オフィスのサーバー上のアプリは localhost で MySQL に接続し、あなたがそのホスト名をデスクトップクライアントにコピーすると、接続は失敗するか別のデータベースが開きます。VPN はこの語の意味を何も変えていません：localhost は今もクライアントを実行するマシンを指します。VPN が動かしたのはパケットであり、インターフェースではありません。ルートに触れる前に、ノート PC がどのエンドポイントに届くべきかを決めてください。

ステップ 1：ノート PC がどのエンドポイントに届くべきかを決める

どちらの設計も正当で、それぞれ別の問いに答えるので、直接アクセスとは、データベースがトンネルの届くプライベートアドレスで待ち受け、ノート PC がそのアドレスに接続する形です。転送アクセスとは、データベースは loopback に留まり、SSH セッションがポートをあなたのマシンまで運ぶ形です。どちらかを意図的に選んでください。混ぜると、間違った理由で動く接続になります。

直接アクセスなら、データベースホスト自身のプライベート名またはアドレスとそのポートを、管理している人から入手します。VPN ゲートウェイのアドレスは、同じマシンでない限りデータベースのアドレスではありません。次に、インターフェースへのルートはそこにリスナーを作らないので、リスナーが本当にそのインターフェースに束縛されていることを確認します。

ステップ 2：リスナーがローカルに留まる場合だけポートを転送する

データベースを loopback のみに留めるべきなら、SSH で転送し、ローカル側も loopback に束縛します。左側のバインドアドレスはあなたのノート PC のもので、右側のターゲットは SSH サーバー側から解釈されます、OpenSSH のリファレンスに書かれているとおりです。この二つの役割を取り違えるのが、転送が動いているように見えて何にも繋がらない通常の理由です。

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:13306:127.0.0.1:3306 [email protected]
ss -ltn 'sport = :13306'

SSH がデータベースホストではなくジャンプホストに着地する場合、右側の loopback はジャンプホストを指し、ターゲットはそのホストが届くアドレスに変える必要があります。ExitOnForwardFailure は転送の確立失敗を捕まえますが、その後のターゲットへの接続が成功することを証明しません。ホスト鍵の確認は有効のままにし、すべてのインターフェースに束縛して転送ポートを LAN 全体に公開しないでください。

データベースを loopback のみに留める必要があり、SSH を使えないなら中止してください。その場合、直接アクセスは間違った設計であり、押し通す設定ではありません。

ステップ 3：クライアントを TCP に強制する

Unix では、localhost を渡された MySQL クライアントは既定で Unix ソケットを選ぶため、ポートだけを変えると、転送とは無関係なソケットを探し続けることがあります。明示的な TCP プロトコルと loopback アドレスを使って、クライアントに転送ポートへの接続を開かせてください。

mysql --protocol=TCP --host=127.0.0.1 --port=13306 --user=DB_USER --password

値のないパスワードオプションは、秘密をコマンドラインに置く代わりに問い合わせるもので、これは保つ価値のある習慣です。他のツールにも同じ区別のための独自のスイッチがあり、一部のドライバーも localhost を特別に扱います。フラグが引き継がれたと決めつけず、クライアントが何をするかを確認してください。データベースアカウントには、サーバーが見る送信元に一致する権限も必要で、それはノート PC ではなく転送ホストです。

ツールを TCP に強制できないなら中止してください。その場合は別のクライアントを使うか、プライベートリスナーへの直接アクセスを使ってください。

ステップ 4：実際にどのエンドポイントに届いたかを証明する

サーバーに、その接続を何だと思っているか尋ねてください。ホスト名、ポート、ソケットの変数は、TCP で来たかどうかとどのリスナーが応答したかを示し、接続一覧はサーバーが記録した送信元アドレスを表示します。その証拠は、もう一つのルート変更より役に立ちます。

mysql --protocol=TCP -h 127.0.0.1 -P 13306 -u DB_USER -p -e "SELECT @@hostname, @@port, @@socket"

どのエンドポイントを試したか、つまりローカルの Unix ソケット、転送ポート、プライベートリスナーのいずれかを記録してください。この三つの失敗は修正方法が異なり、クライアントがまだ間違った localhost と話している間に VPN のルートを変えるのは無駄な労力です。メモでは SSH 認証とデータベース認証も分けておいてください、デスクトップクライアントからは一方の失敗が他方の失敗のように見えるからです。最後に、使い終わった転送を削除してください。

チェックリストは、エンドポイント、クライアントのプロトコル、サーバーが見た送信元アドレス、それを許可した権限を言えるときに終わります。四つの事実があり、次の接続問題は午後ではなく数分で片付きます。