Linux EHOSTUNREACH と OpenVPN: どの次ホップが失敗したのか

EHOSTUNREACH は遠隔の障害であると同じくらい、ローカルの判断でもあります。カーネルがパケットを拒否するのは、ルートが宛先を到達不能と示しているため、Ethernet の次ホップが一度も応答しなかったため、あるいは経路のさらに先から ICMP host-unreachable の報告が届いたためです。それぞれの原因は別のテーブルやキャッシュに存在し、修正する場所も異なります。暗号やトンネルの再インストールに触れる前に、選択されたルートと次ホップの状態を読み取ってください。

クライアントが実際に使うアドレスと名前空間を選ぶ

エラーを生じさせた宛先とネットワーク名前空間を固定することから始めます。VPN クライアントは独自の名前空間で動作することがあり、既定の名前空間からの検索は別のポリシールールを持つ別のルーティングテーブルを参照します。

検索は、失敗しているアプリケーションと同じ送信元・マーク・テーブルのコンテキストを使わなければなりません。そうでなければ誰も尋ねていない質問に答えてしまいます。例示的な IPv4 ピアの場合、読み取り専用の確認は次のとおりです:

ip -4 route get 198.51.100.25
ip -4 neigh show 198.51.100.1
ip -4 route show table all | grep -w unreachable

管理用シェルでの結果は、そのシェルが何をするかしか証明しません。クライアントがファイアウォールマークを設定したり VRF にバインドしたりする場合は、対応するマークを付けて、または VRF の内部で検索を繰り返し、選択されたルートと次ホップを比較してください。最初に確認すべきアドレスはプロファイル内のピアアドレスであり、ユーザーが名指しするクラスタやサービスではありません。

明示的な到達不能ルートはパケットをローカルで拒否する

unreachable 型のルートは意図されたローカルな応答である。カーネルにパケットを破棄させ、EHOSTUNREACH を送信者に返させるため、エラーは瞬時に、しかもマシンから出る通信なしで現れます。誰か、あるいは何らかの自動化が、そのルートを意図的に置いたのです。

ルートの種類は互換ではありません。blackhole は送信者にエラーを返さずにパケットを破棄し、prohibit は EACCES を返し、unreachable は EHOSTUNREACH を返します。そのため、再接続中にシンクルートを設定する VPN ヘルパーは、トンネルが上がると消える host-unreachable エラーの急増を生むことがあります。一方、blackhole ルートなら代わりに無言のタイムアウトが生じます。

遠端を責める前に、すべてのテーブルで種類を検索してください。テーブルを選ぶルールは、その中のルートと同じくらい重要であり、メインテーブルに追加したルートは、ポリシールールが通信を別の場所へ送るクライアントには役立ちません。

死んだ隣接ノードは Ethernet でも同じエラーを生む

選択されたルートがオリンクのゲートウェイを使う場合、配送には解決済みのリンク層アドレスが必要です。カーネルは ARP または IPv6 の隣接要請を送り、応答がなければパケットをフレーム化できません。そのときルート自体は有効でも、送信は EHOSTUNREACH で失敗します。

隣接テーブルは段階を名指しします。INCOMPLETE は解決がまだ進行中、FAILED は最後の試行が応答を得なかったこと、REACHABLE または STALE はカーネルが使用可能なアドレスを持つことを意味します。VPN ゲートウェイの FAILED エントリはローカルの配送問題であり、トンネルの遠端についての証拠ではありません。

実際の次ホップのエントリを読んでください。遠隔のインターネットアドレスのものではありません。遠隔アドレスは通常ルーターを経由して到達するため、独自の ARP レコードを持ちません。それを求めるのはカテゴリー錯誤であり、存在するはずのないエントリを探させてしまいます。

遠隔の報告と非同期 UDP エラー

EHOSTUNREACH は外部から届くこともあります。パケットを転送できないルーターが ICMP host unreachable を送り、カーネルはその報告をフローを所有するソケットに渡します。その場合、ルートと隣接は正常であり、障害はローカルネットワークの先のホップに属します。

UDP は原因の帰属を難しくします。後続の送信または受信呼び出しが返すエラーは、以前のデータグラムを指すことがあるため、失敗した呼び出しのアドレスと時刻が、報告を引き起こしたパケットと一致しないことがあります。接続済みの UDP ソケットはエラーを一度受け取り、未接続のソケットはまったく見ないかもしれません。

だからこそ時刻は証拠の一部です。エラーがいつ現れたか、ソケットがどのピアアドレスを使ったか、トンネルがちょうど再接続したかを記録してください。ルート変更直後の急増はローカルテーブルを指し、安定したフローの数分後に単発で出るエラーは経路の報告を指します。

暗号を変える前に層を分ける

三つの質問がエラーを分類します。カーネルは宛先を拒否するルートを選んだのか。有効なルートを選んだが次ホップを解決できなかったのか。それともローカルネットワークの外から報告が届いたのか。トンネルの遠端を巻き込めるのは三番目だけであり、その場合でも暗号化は巻き込みません。

認証とネゴシエーションの問題は、トランスポートがピアに到達した後に独自のエラーとして現れます。暗号を変えたりクライアントを再インストールしたりしてもローカルの unreachable ルートは直らず、本当の原因に必要なルートと隣接の証拠を壊してしまいます。

最初の変更の前に、宛先、名前空間、選択されたテーブル、次ホップ、隣接の状態、エラーの時刻を記録してください。修正後に同じ検索を再実行してください。今トンネルを指すルートと、今解決される隣接エントリは、無関係なアドレスへの成功した ping より強い証拠です。