TCP リセットは VPN がブロックされている証拠ではない

クライアントのログに「接続がリセットされました、再起動します」と現れ、証拠より先に結論が出ます。ネットワークが VPN をブロックしている、証明書が間違っている、特定の国が干渉している、と誰かが決めます。リセットは接続を終了させる TCP パケットであり、ログ行はクライアントがそれを受け取ったことを記録するだけです。送信した機器も、送信された理由も示しません。

リセットはパケットであり、判決ではない

TCP はリセット処理を定めています。RST フラグを持つセグメントは接続を直ちに終了させます。受信側は交渉も再試行もせず、理由も尋ねません。リセットを報告して先へ進みます。

クライアントが知っているのはそれだけです。RST はサーバー、プロキシ、ファイアウォール、あるいは状態を失ったロードバランサーから来た可能性があります。

送信元の特定は別の作業です。キャプチャに見える送信元アドレスは物理的な発生元の証明ではなく、その背後のポリシー判断について何も語りません。中間装置はアドレスを偽装でき、状態を持つ機器は意図ではなくタイムアウトでリセットすることがあります。リセットを判決として扱うと、本当のことを突き止める部分を飛ばしてしまいます。

どの接続がリセットされたかを確認する

まず、有効なプロファイルが本当に TCP を使っているか確認します。UDP トンネル上のリセットは意味がなく、HTTP プロキシのログは VPN 本体とは別の TCP 区間を指していることがあります。

宛先、ポート、試行時刻、そしてクライアントが到達した段階を記録します。

段階が最も有用な項目です。TLS ハンドシェイク中のリセットは一組の容疑者を示し、認証後のリセットは別の組を示します。段階がなければ、どの説も当てはまります。

経路の両端を比較する

サーバーを管理しているなら、同じ試行に対するサーバーのイベントを比較します。接続を受け入れたか。意図的に閉じたか。応答が一方の境界を出て、次の境界に届かなかったか。

可能ならクライアント側とサーバー側の両方でキャプチャします。クライアントで見えてサーバーで見えないリセットは、サーバーで発生していません。

両方向の RST セグメントに注意してください:

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

制御された比較で絞り込む

承認済みの別ネットワークを使えば、障害がクライアントに付随するのか経路に付随するのかが分かります。同じプロファイルが別の場所で動くなら、クライアント設定はおそらく正常で、変数は経路です。

それでも特定の中間装置は分かりません。範囲を経路に絞ることは、有用で正直な結果です。

「この経路が失敗する」と「この名指しの主体が引き起こした」を区別したままにしてください。前者は検証できますが、後者は通常、単一のクライアントからは検証できません。

信頼設定を変えずに修正を確認する

TLS 検証を無効にしたり、資格情報を再生成したり、リセット一行からブロック方針を宣言したりしないでください。どれも試験対象のシステムを変え、次の比較を無意味にします。

特定した構成要素をその所有者を通じて修正し、同じプロファイルと同じ観察を繰り返します:

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

有用な結果は、より良く位置づけられた障害であり、より自信のある物語ではありません。プロキシの修正後にリセットが消えれば原因があります。別の段階に移れば、経路について何かを学んだことになります。いずれにせよ、証拠は第二の読み手に耐えるべきです。観察したことを書き、結論したことを書かないでください。