VPN 経由のリモート SSH：トンネルがやらないこと

VPN は SSH サーバーに専用の経路を与え、ポート 22 で公開リスナーを必要としなくする。ホストを認証せず、ユーザーを認可せず、どのアカウントがログインできるかも決めない。それは SSH の仕事のままだ。VPN がサーバーに到達する正しい方法かどうかは三つの条件で決まり、トンネルは可能な答えの一つにすぎない。

トンネルが変えるものと SSH がなお決めるもの

トンネルが変えるのは到達性、つまりどのアドレスにどこから到達できるかだ。TCP 接続が届いた後に、サーバーがホスト鍵を提示してユーザー ID を求める段階で何が起きるかは変えない。

二つの層は頭の中でも文書の中でも分けておく。VPN へのログインは、誰がネットワークを使えるかを証明する。対象にどのアカウントがあるかは何も語らず、到達可能なすべてのマシンにサインインする許可でもない。

失敗の様式も別であり、それこそが障害時にこの分離を役立てる。

アクセスモデルを決める三つの条件

第一に、サーバーはあなたのネットワークの外の人から到達可能である必要があるか。必要ないなら、専用経路に踏み台かメッシュを加えたほうが小さな設計だ。第二に、制限のある管理対象デバイス上のものも含めて、クライアント群は実際に VPN クライアントを実行できるか。

第三に、サービス単位の制御が必要か、ユーザー単位の制御が必要か。VPN はネットワークへの到達を与え、SSH はアカウントへのアクセスを与える。請負業者が一つのホストにだけ到達すればよいという要件なら、それは認可の要件であり、トンネルだけでは表現できない。

この三つに答えれば、モデルはおのずと決まる。飛ばせば、クライアントの展開を避けるために SSH を公開することになる。

SSH を責める前に専用経路を確認する

承認された VPN に接続し、対象の文書化された専用の名前かアドレスを使う。次に、選択された経路、ゲートウェイの許可、クライアントへの戻り経路を確認する。正しく解決する名前は、ローカルとリモートのプレフィックスが重なると要求がまったく別の場所へ送られることがあるため、そのアドレスが意図したトンネルを通る証拠にはならない。この違いはランブックに書く価値がある。

接続がまったく届かない場合は、サーバーが想定したインターフェースで待ち受けていることと、そのホストファイアウォールが実際に見える送信元を許可していることを確認する。ゲートウェイの NAT がその送信元を書き換えることがあるため、クライアントのトンネルアドレス向けに書かれた許可リストが決して一致しないこともある。

その不一致が、VPN 上の SSH で最も多い自己誘発的な失敗だ。

複合エラーではなく失敗の段階を読む

三つの段階は三つの異なるメッセージを生み、そのうち資格情報に関するものは一つだけだ。

VPN と SSH の資格情報を同時にリセットするのではなく、正確なエラーとサーバー自身のログを使う。両方をリセットすることが、五分の診断を二日間の ID インシデントに変える道だ。

詳細出力は、どの段階に達したかを示す：

ssh -vv [email protected]

ホスト鍵と認可を保つ

ホスト鍵は、特にサーバーを交換した後は、意図した信頼できる手順で検証する。予期しない鍵変更の警告は、専用トンネルが接続先をあなたの思うマシンにするわけではないからといって、VPN が接続したという理由だけで無視してはならない唯一のメッセージだ。指紋は、接続とは独立に信頼できる情報源と照合する。

サーバー側では、アカウントが認可されていることと、設定した認証方式が提示されている方式であることを確認する。存在するのに無視される鍵は、通常はネットワークではなく権限か設定の問題だ。

サービスへのアクセスを必要な ID に限定し、ネットワーク変更のための認可された復旧経路を保つ。