PPP の peer アドレスと VPN エンドポイント: via に入れるのはどちらか

PPP インターフェース上の一行、つまり内側のアドレスとその隣に表示される peer が、VPN マシン上のルーティング論争のほとんどを決着します。この組を小さなサブネットとして読めば、存在しないゲートウェイを探すことになります。一本のリンクの両端として読めば、次のホップは明らかです。ここでの比較はこの二つの読み方の間のもので、後から作るどのテーブルも選んだ読み方を引き継ぐからです。外側の VPN エンドポイントについては、どちらも何も決めません。

一本のインターフェース行に対する二つの読み方

インターフェースが inet 10.64.3.9 peer 10.64.3.1/32 と報告するセッションを取り上げます。サブネットとしての読み方は、10.64.3.9 を /32 の島に孤立したホストとみなし、その外側へ届くためのルーターを探します。リンク上のもう一つのアドレスが peer だけなので、この読み方は結局 10.64.3.9 自身をゲートウェイとして提案し、循環します。

エンドポイントとしての読み方が文書化されている側です。ポイントツーポイントのインターフェースでは、peer はその一本のリンクの遠端を指すので、10.64.3.1 が使える次ホップであり、10.64.3.9 は常に送信元アドレスにすぎません。

この違いが via に何を書けるかを左右します。そこにローカルアドレスを書くと、カーネルが隣接ホストに解決できないルートになり、エントリは検証で落ちるか、一覧では完全に健全に見えたままトラフィックを吸い込みます。peer はリンク上の実在の宛先なので機能します。両方の読み方は、まったく別の同一性である外側の VPN エンドポイントについても一致し、そこへはアンダーレイ経由で到達し、それが終端するトンネル経由ではありません。

セッションがすでに導入しているもの

自分のテーブルを書く前に、リンクと一緒に来たものを表示します。対応する PPP 統合は通常、セッション確立時にデバイスルートと peer ルートを導入し、その二つのエントリがすでに正しい読み方を符号化しています。

ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5

10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 のようなデバイスルートは、インターフェース自体が経路なのでゲートウェイを持ちません。peer を via で指定するルートは別の寿命を持つ別のオブジェクトで、セッションが切れると消えます。どちらかの形式を、再導入の方法を確かめずに永続テーブルへコピーすることが、動いていたトンネルが再接続後にルートを失う通常の原因です。

記憶を信じるのではなく、二つの一覧を比較します。peer ルートが main に存在するのに追加テーブルが空なら、アドレス行が決して教えなかったことを学んだわけです。

ルールとテーブルは別々の決定

テーブルを選ぶことと埋めることは独立した手順で、デバッグ中にこの二つが混同されがちなので比較が効きます。マークしたトラフィックをテーブル 100 へ送るルールは、テーブル 100 に一致するルートがなければ何もせず、よく埋まったテーブルも、それを指すルールがなければ到達できません。

デフォルトルートの半分はデフォルトルートではありません。一つの 0.0.0.0/1 は IPv4 空間の下半分を覆うだけなので、すべてを捕まえるつもりのポリシーには対応する 128.0.0.0/1 か、本物の default も必要です。動く設定を読んで二つの半分の片方だけをコピーするのが、特定の宛先でだけ壊れるルーティングループに陥る道です。

LAN に残すべきアドレスには意図的な例外を残し、選択したテーブルで何も見つからないときに何が起きるかを決めます。明示的なフォールバックルートは、到達不能を返してアプリを誤ルーティングではなく壊れて見せる空のテーブルより考えやすいものです。

アプリケーションが尋ねる質問を検索に尋ねる

経路を解決する ip route get と、保存されたエントリを一覧する ip route show は、どちらも間違っていないのに食い違うことがあります。送信元ベースのルールは検索が送信元を運ぶときだけ一致するため、送信元の文脈を含めてください。

ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show

最初のコマンドはホスト側からの問いです。二番目は入力インターフェースを加え、転送されるトラフィックが経験するものに近づき、答えはしばしば別のテーブルを指します。どちらの宛先も実際のテストサービスではなく、198.51.100.23 はドキュメント用アドレスなので、調査を許可されたホストに置き換えてください。

正しい検索でも、経路が選ばれたことしか証明しません。相手側がトラフィックを受け入れるか、応答が同じ推論で戻れるかについては何も言いません。

比較が反転する場所

ホストのトラフィックと転送されるトラフィックは、違う検索をするだけでなく、戻り道で違うフィルターに遭遇します。Linux は逆経路検証を、全インターフェースと受信インターフェースの設定のうち厳しい方で適用するので、一つのインターフェースの値を変えても目に見える効果がないことがあります。マークベースのルーティングは src_valid_mark の関係を加え、送信元が有効とみなされるにはマークが一致する必要があります。

外向きのルーティングが正しく見えるのに応答が消えるなら、触る前に実効値を読み、明示したポリシー上の理由があるときだけ変更します。

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark

証拠に基づいて選ぶなら、アプリケーションが PPP アドレスに束縛されるときは送信元ルールと peer ルートを持つテーブルで足ります。ボックスが背後の LAN のために転送するなら、入力の文脈と戻り道も一致している必要があります。一致しないときは、マシン全体の検証を緩めるのではなく、ルートの所有権を直します。