VPNゲートウェイにIP転送が必要: 何を確認すべきか

クライアントがゲートウェイのアドレスにpingできても、その背後のリソースはすべて到達不能なままである。この二つの観察は、あなたと通信しているホストと、ルーティングしていないルーターという、同じマシン上の別の役割を表している。転送はその間のスイッチである。

二つの役割は独立しており、二つのアドレスファミリーも同様である。

自分のアドレスへの応答は何も証明しない

パケットがゲートウェイ自身に宛てられている場合、ローカルスタックがそれを消費し、転送の判断は行われない。だからトンネルのアドレスや管理インターフェースへのpingの成功は、デーモンが生きていてトンネルが上がっていることを教えるが、ボックスの背後のネットワーク宛てのトラフィックについては何も語らない。カーネルは自分宛てでないパケットについてのみ転送経路を参照する。

要件は設定ではなく役割として読むべきだ。このホストは二つのインターフェース間でパケットを動かさなければならない。遠隔ネットワークに到達するだけでよいノートPCは決してその役割を負わず、サイト間エンドポイントは常に負う。そう読めば、動作していたクライアント設定がゲートウェイに移すと失敗する理由が説明できる。

同じことは転送の判断の前にあるファイアウォールにも当てはまり、何を転送してよいかについて独自のポリシーを持っている。

アドレスファミリーごとに別々に確認する

IPv4の転送は一つのスイッチであり、IPv6の転送はインターフェースごとの挙動を持つ別のスイッチである。前者を有効にしても後者については何も言えず、デュアルスタックのクライアントはネットワークの半分に到達できても残りは暗いままになりうる。したがって異なるファミリーの二人のクライアントが同じゲートウェイについて意見を異にすることがある。どちらの設定を編集する前に、失敗しているクライアントがどちらのファミリーを使ったかを尋ねよ。ルーティング設計が誤っていると結論する前に両方を確認せよ。

sysctl net.ipv4.ip_forward
sysctl -a --pattern 'net.ipv6.conf.(all|default).forwarding'
nft list ruleset | head -n 40

多くのディストリビューションでは、実行時に読む値はサービスや設定ファイルが置いたものであるため、一回限りのコマンドで行った変更は再起動で消えることがある。実行時の値を編集する前に、その設定を所有するファイルを見つけよ。

転送は四つの要件の一つである

動作する転送フローには同時に四つのものが必要だ。クライアントは宛先がトンネルの背後にあると知っていること、ゲートウェイには先への経路があること、応答には戻り経路があること、ファイアウォールがトラフィックを許可することである。送信元変換は規則ではなく選択肢としてその設計に属する。対称な経路を持つプライベートなルーティングネットワークには不要であり、非対称なものには通常必要だからだ。四つのうちどれか一つが独立して失敗するので、一つを直しても症状はほとんど動かない。どれかを変える前に四つとも書き出せ。

クラウドプラットフォームは五つ目の考慮事項を加える。インスタンスで送信元と宛先のチェックを強制するものがあり、ゲストのカーネルがどう設定されていても転送パケットを落とす。そこでの権威はプラットフォーム自身のネットワーク文書であり、VM内のsysctl出力ではない。

ゲートウェイではなくクライアントからテストする

ゲートウェイ自身のシェルで実行したテストは、いま有効にした転送経路をまったく通らない。問題のあるクライアントからトラフィックを生成し、それがゲートウェイ自身ではなく背後の何かに届くことを確認せよ。変更した役割を試す唯一のテストである。

リスナーの規則と転送の規則を頭の中でも変更記録でも分けておけ。VPNポートを開けることはクライアントをサービスに受け入れる。その背後のネットワークでは何も与えず、何年も育ったファイアウォール一覧では両者は同じに見える。

パケットが届いてサービスが利用者を拒否するなら、ネットワークの範囲を超えている。転送ポリシーを再び広げるのではなく、アプリケーションの認可に進め。