VPN 経由の MariaDB:サーバーが見る user@host はどれか
アカウントはユーザーとホストの組み合わせで選ばれます。サーバーが見た送信元を突き止め、CURRENT_USER() を読み、その行を修正します。権限ではありません。
同じユーザー名を 二つの異なる経路から入力すると、MariaDB はあなたを 二つの別アカウントとして認証するかもしれません。アカウントはユーザーとホストの組み合わせで識別されるため、'reporter'@'localhost' と 'reporter'@'10.90.0.23' は別の行であり、パスワードも権限も別です。VPN 経由で興味深いのは、ユーザーが入力した名前ではなく、サーバーが観測した 送信元アドレス。
サーバーが実際に見る送信元を特定する
ノート PC ではなくデータベースホストから逆向きにたどります。クライアントが持っていると信じているアドレスは、いくつかの可能性のうちの一つにすぎません:
| Path | Source MariaDB sees |
|---|---|
| Routed tunnel, no translation | The client's inner VPN address |
| Gateway source translation | The gateway's translated address |
| SSH local forward | The SSH server's address |
| Public exit, no tunnel | Whatever the ISP handed out |
サーバー側の証拠で決着させます。接続ログ、アクティブなセッション一覧、あるいは一般ログの一時的な記録が、サーバーが受け入れたアドレスを示します。ブラウザーから見えるノート PC のパブリック IP は別の事実であり、しばしば誤解を招きます。
MariaDB が選んだアカウントを突き合わせる
アカウントの選択は権限の合成ではなく、文書化された順序に従います。ホストの完全一致はワイルドカードより優先され、匿名ユーザーの行は、名前だけで決まると考える人を驚かせる形で照合に加わります。サーバーは 一つの行を選ぶのであって、同名の行すべての権限を統合するわけではありません。リファレンスを 一度読むほうが、半日推測を試すより価値があります。
つまり、セッションが 'reporter'@'10.90.0.23' として認証された場合、'reporter'@'%' に権限を追加しても何も変わらないことがあります。修正は選ばれた行に当たらなければならず、そのためアカウントの特定が権限の編集より先になります。
セッションが実際に使うアカウントを読む
SELECT USER(), CURRENT_USER();
SHOW GRANTS;
CURRENT_USER() はセッションを認証したアカウントを示し、USER() はクライアントが要求したものを報告するため異なることがあります。これらは通常の最上位クエリとして実行し、定義者コンテキストを持つストアドルーチンの中から実行しないでください(そうしないと、答えはあなたのセッションではなくルーチンの所有者を説明します)。
失敗したログインはこれらを一切実行できないため、管理者がアカウント定義とサーバーの接続証拠を調べる必要があるのはこの場合です(それに備えてください)。拒否されたログインをデバッグする人には、通常問い合わせる SQL セッションがありません。
到達性と認証を分けて考える
エラーの文言は、どの層にいるかを教えてくれます。接続拒否やタイムアウトは、クライアントがリスナーに到達しなかったことを意味するので、アカウントとパスワードはまだ問題ではありません。アクセス拒否の応答は、サーバーが応答したことを意味し、到達性を証明してアカウント、ホスト一致、資格情報のいずれかを指します。
ネットワークの前提条件はそれ自体が一覧です:意図したアドレスにバインドされたリスナーであり、ループバックだけに限定されないこと、設定したポートへの通信が許可されていること、応答の戻り経路があること。それぞれが独立に失敗し得て、動くトンネルはそのどれも意味しません。ループバック上のリスナーはローカル接続を受け入れ、あらゆるリモート接続を拒否するため、ファイアウォールのブロックに見える接続拒否が生じます。
ネットワークチームにチケットを開く前にバインドアドレスを確認してください。データベースホスト上の ss -lntp は、どのアドレスとポートが実際に待ち受けているかを示し、その一行で推測のカテゴリ全体が排除されます。
狭く修復し、その後に両方向を再テストする
意図したホスト修飾アカウントを組織の承認済み手順で作成し、資格情報はサポートされたストアから取得して、チケットに貼り付けた共有のものを使いません。タスクに必要なスキーマ操作だけを付与します。失敗したリモートログインを root アカウント、全許可ポリシー、包括的なワイルドカードホストに変えると、テストは通りますが、テストしていた統制が失われます。慌てて追加した権限は、後で誰も外さない権限です。
意図した経路で新しいセッションを使って再テストし、その後で否定的なケースを確認します。ブロックされるべき経路は依然としてブロックされ、付与されていない操作は依然として拒否される必要があります。この二つの確認が、修復されたアカウントと拡大されたアカウントを分けます。
最後に、観測した送信元アドレスとアカウント名を一緒に記録します。トンネルは到達性を提供しますが、MariaDB は依然として独自にアカウントを選び認可し、次の人があなたの結果を再現するには、両方の事実が必要です。