
VPN を実行しようとしています。 のようにすべてのトラフィックをルーティングするのではなく、プログラムがインターフェイスを明示的に要求するようにしたいと思いますcurl --interface
。
curl --interface ppp0 ip.bsd-unix.net
VPN経由で送信する必要がありますが、何らかの理由で、tcpdump
またはを使用してiftop
、送信元IPが10.10.1.2であっても、トラフィックがeth0を通過していることがわかります。. これが私のですip route show
:
default via 149.x.y.z dev eth0
10.10.1.1 dev ppp0 proto kernel scope link src 10.10.1.2
149.x.y.128/25 dev eth0 proto kernel scope link src 149.x.y.172
一部の IP は隠されています。2 番目の IP は xl2tp の起動時に追加され、ppp0 インターフェイスが作成されます。149.etc は私の LAN で、10.etc は私の VPN です。
また、 の場合、ping -I ppp0 8.8.8.8
ppp0 アクティビティを確認でき、VPN を経由していることを示唆するより高いミリ秒の応答が返されます。
答え1
私は、パケットの送信元 IP がインターフェースの IP と一致する場合、そのインターフェースが使用されるだろうと想定していました。そして、それが IP 本来の動作でなければ、2 番目のルートでそれが起こったはずです。src
ルートのその部分は私にとっては誤解を招くものでした。
つまり、私のプログラムは ppp0 アドレスにバインドされ、それがソース IP を設定するわけですね? @davidgo の言うとおりにして、別のルーティング テーブルを作成しました...
echo 200 custom | sudo tee -a /etc/iproute2/rt_tables
...次に、その送信元 IP を持つパケットにカスタム テーブルを使用するルールを追加しました...
sudo ip rule add from 10.10.1.2 lookup custom
...そして、カスタム テーブルにルールを追加し、ppp0 のゲートウェイを通過するすべてのトラフィックに ppp0 を使用するようにしました。
sudo ip route add default via 10.10.1.1 dev ppp0 table custom
curl ip.bsd-unix.net
自宅の IP とcurl --interface ppp0 ip.bsd-unix.net
VPN のリモート IP が提供されます。うまくいきました!
それでも、なぜ ping がずっと ppp0 を正しく通過していたのかは興味深いです。