Redsocks はループバックで待ち受けるが VPN トラフィックは届かない

トンネルが立ち上がり、クライアントはゲートウェイに ping できるのに、プロキシ経路を通るすべてのウェブリクエストが死にます。redsocks プロセスは動作していてポートも待ち受けているため、ゲートウェイ自身から見るとサービスは健全に見えます。失敗しているのは配送の段階であり、トンネルからリダイレクトされたパケットは、あなたが起動したソケットに着地しません。バインドアドレスとリダイレクト先は一致している必要があり、通常はそのどちらか一方しか確認されません。

リダイレクトされたパケットが実際に着地する場所

ゲートウェイ上の透過プロキシは、PREROUTING の nat テーブルで REDIRECT を使い、受信接続の宛先をローカルポートに書き換えます。書き換えられた宛先は、パケットが到着したインターフェースから見たローカルアドレスであり、別の場所で起動したプロセスのループバックアドレスではありません。127.0.0.1 だけにバインドされたリスナーは、すでにホスト上でローカルだった接続を受け付けますが、これはまさにトンネルのトラフィックが失敗している間も動き続けるケースです。クライアント自身のループバックは三つ目のアドレスであり、ゲートウェイのルールの対象になることは決してありません。

したがって、上流の認証情報に触る前に、ルールがどのローカルアドレスに書き換えるのか、プロキシのソケットがどのアドレスにバインドされているのかという二つの事実を確定してください。

リスナーとリダイレクトルールを一緒に読む

ソケットテーブルと nat ルールは、誰も所有していないポートを指すルールが間違ったアドレスを指すルールと見分けがつかないため、同じパスで出力してください。sudo ss -ltnp | grep redsocks はバインドアドレスと所有プロセスを示します。sudo iptables -t nat -S PREROUTING は REDIRECT の宛先を示し、sudo iptables -t nat -L PREROUTING -v -n はそれに一致したものがあるかを示します。

REDSOCKS という名前のユーザーチェーンへのジャンプは、そのチェーンが存在し、意図した除外と REDIRECT アクションを保持していなければ何も達成しません。名前が仕事をするものと仮定せず、ジャンプ先のチェーンを sudo iptables -t nat -S REDSOCKS で読んでください。

次に二つの値を比較します。ルールがポート 12345 のゲートウェイアドレスにリダイレクトし、リスナーが 127.0.0.1:12345 を報告するなら、その不一致だけで追加の診断なしに失敗を説明できます。

狭くバインドし、それから到達できる範囲を制限する

上流のサンプル設定がリスナーをループバックにするのは、透過プロキシがそこに到達できるあらゆる人の代理で接続を受け入れるため、理にかなっています。バインドを 0.0.0.0 に変えると配送は直りますが、同時にすべてのインターフェースでポートが開き、これはセキュリティの変更であって中立的な修理ではありません。リダイレクトが狙う特定のローカルアドレスにバインドすることを優先し、信頼できないインターフェースではポートを閉じたままにしてください。より広いバインドが避けられない場合は、トンネルの送信元範囲とゲートウェイ自身のローカルトラフィックだけを許可するホストファイアウォールルールを追加します。

パブリックインターフェースでポートを開けることは、書き換えの後で接続がローカルで終端するため、リダイレクトされた VPN トラフィックには決して必要ありません。ローカルのリダイレクトを機能させるためにプロキシをインターネットに露出しないでください。

クライアントからの新しい接続で証明する

ゲートウェイ上のシェルからではなく、実際の VPN クライアントから新しい TCP 接続でテストしてください。クライアント上の curl -sS -o /dev/null -w '%{http_code}\n' http://example.com がリダイレクトされた経路を端から端まで試します。

次に、信頼できないネットワークからリスナーへの直接接続が依然として拒否されること、プロキシ自身の上流接続が同じルールで再び捕捉されないことを確認します。再帰的な捕捉は、自分自身に接続してリクエストを完了しないプロキシとして現れます。プロキシの宛先を除外セットに追加するか、その送信パケットにマークを付けてチェーンがスキップするようにします。

最後に、この経路が扱わないものを覚えておいてください。通常の redsocks の TCP リダイレクトは UDP、QUIC、DNS を SOCKS トラフィックに変えませんし、プライベートな宛先には通常明示的な除外が必要です。ローカルテストの成功は、問題ではなかったループバック経路を証明するだけです。