その行には PID_ERR replay-window backtrack occurred と書かれており、検索結果はどれもこれを落ちたパケットと壊れたトンネルだと説明しています。Community OpenVPN 2.6 の UDP 経路では、受信関数がまだパケットをどう扱うか決めている最中に、このメッセージが書かれます。新しい最大の後退を記録し、その後、同じ関数が受け入れるか拒否する前に、距離をウィンドウと記録済みの状態と比較します。ログのラベルを判決として読むことが、このチェックリストが防ごうとしている誤りです。

第一の停止点:その行が何なのかを特定する

これはシーケンス距離についての診断であり、接続についての判断ではありません。パケット ID 実装のうち、新たに観測された最大の後退が記録される箇所に現れます。その箇所は受け入れか拒否かの分岐より前にあるため、それを引き起こしたパケットでも配送されることがあります。

どのホストが、どの詳細度で書いたのかを確認してください。サーバーもクライアントもパケット ID のメッセージを出せますし、片側のメッセージはもう片側の受信状態について何も語りません。

第二の停止点:そのパケットの結果を見つける

診断そのものではなく、その後に続く行を読んでください。同じ関数はウィンドウと重複の確認へと進むので、その特定のパケットの結果は数命令あとで決まり、受け入れであることも十分あります。恐ろしい行で終わるログの抜粋は、結果について何も教えてくれません。行そのものではなく、その周辺のウィンドウを検索してください:

journalctl -u openvpn-server@server --since "-10 min" | grep -n -A3 -B3 "backtrack occurred"

その時点でそのピアに拒否が記録されていなければ、この行を障害の原因とみなすのをやめ、アプリの経路へ進んでください。接続はしたが通信がないという報告の多くは、実際そこに落ち着きます。

第三の停止点:並べ替えが実際にあるかを判断する

並べ替えは経路の性質であり、一つの診断はその一つの標本にすぎません。短いウィンドウの中で同じピアのメッセージが繰り返されるかを見て、ネットワークが激しく並べ替えていると結論づける前に、両端のキャプチャと比べてください。

再接続の間にいくつかのメッセージが出るのは珍しいことではありません。実際のアプリのタイムアウトと並行して流れ続けるなら調べる価値があり、その組み合わせはラベルではなく証拠です。

第四の停止点:ウィンドウのパラメーターと、そうでないもの

replay-window はシーケンスの大きさと任意の時間値を受け取るので、広げると二つの異なる許容度が同時に変わります。数を増やすと順序からより遠いパケットを受け入れ、時間値はパケットをまだ考慮できる長さを制限します。広げることはセキュリティのコストを伴う方針変更であり、暗号を強くもせず、重複検出を無効にもしません。二つの許容度は、意図したかどうかに関わらず一緒に動きます。

古い認証済みパケットも依然として望まない繰り返しになり得るので、受信側はこれらの確認を保ちます。より多くの並べ替えを受け入れることは、そのリスクをより多く受け入れることです。

mute で警告を黙らせると、見えるものは変わりますが、デーモンの動作は変わりません。目的が既知の出来事の間の静かなログならそれは正当な運用上の選択であり、トンネルの修復なら黙らせることは証拠を隠します。

mute 20
replay-window 64 15

外側のトランスポートを TCP に変えると配送と復旧の挙動が変わり、先頭ブロックのコストも加わります。これは設計上の判断であり、一つのログのラベルへの最初の対応ではありません。サーバーを再インストールするのはさらに悪く、統計と実際に失敗した境界の区別を消してしまいます。

第五の停止点:利用者にとって大事な経路を試す

トンネルをつないだ状態で、アプリ自身のテストを実行し、選ばれた経路、転送状態、戻りの経路を読みます。一方向にしかパケットを運ばないトンネルは後退のメッセージをまったく出さず、それは深刻な並べ替えよりもずっとよくあります。

各停止点で何を測ったかを書き留めてください。その記録が、次の報告がまた恐ろしい行から始めてそこから外へ作業するのを止めます。

パケット ID の実装は統計と判断の順序を示し、マニュアルはウィンドウのシーケンスと時間の範囲を説明しています。この二つを一緒に読むことが、恐ろしいログの行を既知の量に変えます。どちらも自分の特定の経路については何も語らず、だからこそ上の測定が今も意味を持ちます。

関連記事