net.ipv4.conf.default.forwarding が tun0 に触れない理由

あなたが設定したのは net.ipv4.conf.default.forwarding=1 です。VPN を再起動しても、トンネルはゲートウェイがルーティングすべきパケットを依然として捨てています。ファイル上の設定は正しく見え、インターフェースは転送が無効のままと報告します。壊れているわけではありません。変更したのは今後のインターフェースが引き継ぐ値であり、稼働中のトンネルが使っている値ではないのです。

トンネルを所有するホストで、トンネルが実際に存在するネットワーク namespace の中で確認してください。コンテナやネットワーク namespace がインターフェースを保持し、ホスト側は別の数値を表示していることがあります。

三つの値を並べて読む

まず、ゲートウェイ全体のスイッチ、新しいインターフェース用のテンプレート、そして気にしているインターフェースを比べます。tun0 を実際の入力インターフェースに置き換え、戻り側のインターフェースも読んでください。転送はパケットが到着する地点で評価されるからです。

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

よくある結果は ip_forward = 0、default.forwarding = 1、そして tun0.forwarding = 0 です。最初の二つはホストの役割について食い違っており、三つ目はインターフェースが実際に何をしているかを示します。この組み合わせは、ルーターとして設定されたことのないホストにテンプレート値だけが与えられた状態と一致します。三つの数値は矛盾しているのではなく、三つの別の問いに答えているのです。テンプレート値を書いても、ホストの役割は決まりません。

動くのがグローバルスイッチである理由

net.ipv4.ip_forward はゲートウェイ全体の制御です。これを変えると同じ操作の一部としてインターフェースごとの転送設定が更新されるため、一度の書き込みで既存のトンネルが転送を始めます。default.forwarding はその後で初期化されるインターフェースにしか効かないので、すでに存在していたトンネルは生まれたときの値を保ちます。

カーネルのドキュメントは ip_forward を関連する理由から特別扱いしています。これを変えると、他の IPv4 パラメータの一群がホスト用またはルーター用の既定値に戻ります。そのためこれは粗い道具になります。ゲートウェイの役割を確立する一環として一度設定するのは問題ありませんが、デバッグの小技として何度も切り替えると、時間をかけて整えた設定を黙って書き換えてしまいます。

インターフェースごとの値にも理由があります。意図的に管理されたゲートウェイは、決してルーティングすべきでないインターフェースで転送を切ったままにできます。ホストが別の場所で転送していても同じです。だからこそ稼働中のインターフェースを読むことが重要であり、グローバル値だけでは答えにならないのです。そうした例外は意図的な判断として読み、そのインターフェースがなぜ違うのかを書き留めてください。さもないと次のエンジニアが親切に「直して」しまいます。

設定を正しい場所で永続化する

一度きりの sysctl -w が成功しても、カーネルがその値を受け入れたことの証明にしかなりません。再起動では残らず、再接続のたびにインターフェース設定に関する独自の考えを再適用するネットワークマネージャーでも残りません。ゲートウェイの役割を sysctl の設定ファイルか、そのホストを管理するネットワークマネージャーに置いてください。そのうえで、それを適用するサービスを再起動します。

トンネルでは順序が重要です。マネージャーが起動時にインターフェースを作り、その後に転送を適用すると、インターフェースは古い既定値を引き継ぐ可能性があります。トンネルを作り直すサービス再起動も作成イベントであり、ユニットが健全に見えると見落としがちです。最終的なファイル内容だけでなく、順序を確認してください。

VPN の再接続後と、さらに再起動後に同じ三つの値をもう一度読んでください。新しく作られたトンネルは新しいインターフェースであり、新しいインターフェースは作成時点で有効な既定値を取ります。これらの出来事の間で数値が変わるなら、まだ特定していない何かが設定を適用しています。

間違った道具で直さない

転送が壊れて見えたとき、ファイアウォールを消去したり masquerading を追加したりしたくなります。どちらも転送スイッチには対処しません。転送の状態、転送の許可、宛先へのルート、戻り経路は四つの別々の要件であり、最初の一つだけが sysctl です。

正しい流れでも試してください。ゲートウェイ自身で行う要求は転送をまったく試しません。それはローカルで生成された通信です。問いは、VPN クライアントや LAN のホストから届いたパケットが受け入れられて先へルーティングされるかどうかなので、試験はゲートウェイの背後から始める必要があります。

IPv6 の場合は切り分ける

ここではすべて IPv4 です。IPv6 の転送、ルーター広告、accept_ra の挙動にはそれぞれ独自の制御があり、ipv4 の経路を ipv6 の設定にコピーしても、もっともらしく見えるだけで役に立つことは何も起きません。デュアルスタックのゲートウェイは両方の組を意図的に設定する必要があります。

最後の確認です。値が一致したら、トンネルのルートが宛先に対して選ばれていること、戻りの経路が存在することを確かめてください。ルートのないインターフェースで転送を有効にしてもブラックホールのままで、その失敗はクライアント側からは同じに見えます。