Pingは通るのにVPN経由のSSHが失敗する：どの段階で壊れたか

Pingの応答とSSHログインの拒否は同時に成り立ち、その組み合わせはトンネルを疑う根拠にならない。エコー応答とポート22へのTCP接続は、セレクタもポリシーも異なり、宛先もしばしば異なる別々のテストである。意図したSSH試行を一度だけ記録し、最後に到達した段階を名指しする。その一つの証拠が、十数個の推測的な設定変更に代わる。

一度の試行を記録する。何度も突くセッションではない

クライアントを詳細診断、接続共有の無効化、接続タイムアウトの上限付きで一度だけ実行する。共有を無効にするのは、以前に認証済みのマスター接続が新しい試行に代わって応答し、追っている障害を隠すからだ。

ssh -4 -vv -o ControlPath=none -o ConnectTimeout=10 [email protected]

宛先、アドレスファミリー、タイムスタンプ、最後の非秘密のエラーを残す。IPv4フラグは、この試行が同じ名前へのIPv6経路について何も語らないことも意味するので、そこから一般化しない。試行をどこから行ったかも記録する。VPNゲートウェイ上での確認は、その背後にあるノートPCと同じ視点ではない。この種のチケットの矛盾の多くは、両者を混ぜることから生じる。

第一段階と第二段階：SSHより前のTCP

最初の境界はソケットの到達性だ。アドレス、ポート、そしてパケットが実際にたどる経路である。TCP接続が完了しなければ、その上にはまだ何も存在せず、ホスト鍵やアカウントは無関係だ。

nc -vz 10.90.4.20 22
ip route get 10.90.4.20
tcpdump -ni any 'host 10.90.4.20 and port 22'

記録とクライアントの試行を突き合わせる。SYNが出て何も返らない場合は、フィルタリング、セレクタ、または遠端での経路欠落を示す。リセット付きの応答は、破棄ではなく積極的に拒否している何かを示す。二つ目の境界はSSHプロトコルの交換そのものだ。完了した後に止まるTCP接続は、到達性を越えてネゴシエーション、サーバー応答、パケット処理に入っている。それは別の調査であり、サイズ関連の問題が初めて現実味を帯びるのはそこだ。

第三段階：どの鍵が応答したか

トランスポートが確立すると、クライアントはサーバーのホスト鍵を検証する。ここでの拒否は暗号ではなく識別についての表明だ。相手はポリシーが受け入れない鍵を提示したのである。これを停止条件として扱い、コンソールやホストを再構築した運用者を通じて帯域外で検証する。警告を消すために記憶した項目を削除するのは、唯一拒むべき近道だ。予想外に何かが応答したという証拠を破壊してしまう。

ホストが本当に再構築されたなら、新しい指紋が確認できてから古い記録を削除し、日付と理由を書き残す。次のエンジニアも同じ警告に遭遇し、その文脈を必要とする。

第四段階と第五段階：アカウントと権限

認証は四つ目の境界だ。資格情報が拒否されたなら、サーバーは試行を評価して拒否している。VPNのパスワードではなく、アカウント、サーバーが受け入れる資格情報の種類、サーバー自身のポリシーを確認する。五つ目の境界はログイン成功後の認可だ。認証済みのユーザーでも、シェル、コマンド、サブシステム、転送を拒否されることがあり、クライアントの最後の行だけを読む人にはそれが障害に見える。

パスワード試行が数回失敗したら止める。推測を繰り返すとロックアウトが生じ、それが二つ目の無関係な障害に見え、元のチケットより時間を食う。

ロールバックと残す記録

一度に一つだけ変え、再テストの前に何を変えたかを書き留める。変更で試行が悪化したら、別の修正を積み重ねずに直ちに戻す。元のクライアントと文脈で元の操作を繰り返す。別のマシン、別のアドレスファミリーからのログイン成功は再現ではなく、修正の証明にならない。

共有するものは無害化する。詳細なクライアント出力には内部名、アカウントラベル、鍵のパス、公開鍵識別子が含まれうるので、生のトレースではなく段階的な結論を公開する。