リダイレクトゲートウェイのないOpenVPNクライアントが三角ルーティングを実行し、IPスプーフィングがUbuntuで機能しない
私のサーバーでOpenVPNクライアントを実行して、別の国のリモートネットワークでパブリックIPを取得しています。クライアント構成は次のとおりです。
dev tap
remote a.b.30.7
float a.b.30.7
port 5167
ifconfig a.b.28.178 255.255.255.128
route-gateway a.b.28.129
#redirect-gateway def1
secret woot.key
cipher AES-128-CBC
dhcp-option DNS a.b.8.8
私のサーバー（openvpnクライアントを実行している）がVPN接続によって「引き継がれる」ことがないようにredirect-gatewayにコメントが付けられています。サービスをtap0インターフェース（つまりhttpdなど）にバインドし、別の国でこのIPからWebサイトを実行できます。 openVPNクライアントが実行されているサーバーが稼働しているISPには出力フィルタリングが設定されていないため、VPNのトラフィックは、別の国のパブリックIPを使用してデフォルトゲートウェイのeth0から送信できます。インバウンドトラフィックのみがVPNを介してルーティングされます（つまり、着信httpd要求）が、アウトバウンドトラフィックはVPNパブリックIPでスプーフィングされたeth0から送信されます。 [〜＃〜] any [〜＃〜]がルートやiptablesをいじくり回さなくても、これは問題なく動作します。DEBIANサーバーでは。明らかな利点は、通常のeth0インターフェイスの速度とルーティングがありますが、IPが別の国にあることです。
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
x.y.150.64 0.0.0.0 255.255.255.224 U 0 0 0 eth0
a.b.28.128 0.0.0.0 255.255.255.128 U 0 0 0 tap0
0.0.0.0 x.y.150.65 0.0.0.0 UG 0 0 0 eth0
x.yは実際のサーバーのネットワークであり、a.bはリモートopenvpnネットワークです。
問題？まったく同じことがUbuntuでは機能せず、その理由がわかりません。私はこれを無数のDebianサーバーで問題なく実行しましたが、カスタムルートやiptablesルールはまったくありません。どちらのサーバーもファイアウォールを実行していません。これは非常に基本的な問題であるか、Ubuntuで何らかの奇妙なことが起こっていると思います。リダイレクトゲートウェイのコメントを解除すると（必要に応じて）、VPNがUbuntuサーバーで機能することは注目に値します。ただし、これは私が望んでいることではありません。それでも、メインインターフェイスであるeth0からサーバーにアクセスする必要があります。
Debianサーバートレース（動作中）：
# traceroute -i tap0 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 Hops max, 40 byte packets
1 blah (a.b.29.1) 39.161 ms 39.140 ms 39.332 ms
2 asdf (a.b.30.1) 40.870 ms 40.879 ms 40.850 ms
3 sth-sbb2-ank35-1-ge26-100.dcs.net (217.78.35.5) 40.816 ms 40.818 ms 40.783 ms
4 google-gw.dcs.net (217.78.35.14) 40.780 ms 40.601 ms 40.565 ms
etc. fine here.
Ubuntuサーバートレース（機能していません）：
# traceroute -i tap0 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 Hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
borked.
8.8.8.8グーグルパブリックDNSであること。
VPN IPには、外部からアクセスすることはできません。興味深いことに、もし私がそうするなら：
ssh -b [debian.server.openvpn.client.IP] user@[ubuntu.server.openvpn.client.IP]
接続/ ping /表示できます。これは、ルートテーブルと同じa.bネットワーク（リモートネットワーク上の異なるIP）で、DebianボックスとUbuntuボックスの両方で実行されている2つの別々のVPNクライアントを使用した場合です。 DebianサーバーのVPNクライアントIPは一般公開されていますが、Ubuntuサーバーではアクセスできません。 a.b内からのみ！
目標は、VPNを介してトラフィックを送り返し、VPN帯域幅を浪費するのではなく、トラフィックをeth0からスプーフィングすることです。また、同じVPN構成がdebianサーバーで問題なく機能します。 UbuntuボックスにあるVPNの設定をDebianボックスに置くことができます。それで問題ありません。
Debianサーバーは2.6.32-bpo.5-xen-AMD64でDebian564ビットを実行します
Ubuntuサーバーは2.6.32-24サーバーでUbuntu10.04.1LTSを実行します
Ubuntuサーバーではmodprobe-lでは見られなかったが、debianサーバーではDID）だったので、これはカーネルモジュールとtun.koの問題かもしれないと思った。 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/565856 興味があれば、回避策を試しましたが無駄になりました。それは別のことだと思います。
どんな助けでも大歓迎です！必要に応じて適切なネットワーク用語が不足していることをお詫びします。私は中級のネットワーク知識しか持っておらず、これはdebianで簡単に機能したので、特別なことをする必要はありませんでした。
私はあなたが何を達成しようとしているのかを（まだ）完全には理解していないことを認めなければなりません。しかし、OpenVPN（着信トラフィック）を介して取得したIPでUbuntu（およびDebian）サーバーに到達できるようにしたいが、（Ubuntu）サーバーにローカルなeth0インターフェイスを介して独自の（= Ubuntuサーバー）トラフィックを送信したいと思います（「なりすまし」 "）VPN-IP。またはこれらの線に沿って。これが非常に良いアイデアかどうかはわかりませんが（おそらくそれを行う理由によって異なります）、それには理由があると思います。あなたが言うように、Debianでも機能します。したがって、これについては詳しく説明しません（ただし、後で重要になる可能性があります）。
さらに、なぜラインが
route-gateway a.b.28.129
vPN構成に含まれていても、ルーティングテーブルにエントリが含まれることはありません（そう思われます）。
また、表示されている2つのtracerouteの目標/洞察が何であるかわかりません... VPNトンネルを介して8.8.8.8にtracerouteしようとしているようです。これは送信トラフィックであるため、私はあなたの問題との関連性を本当に理解していません。そして、私は（ルーティングテーブルを見て）この方法で生成したトラフィックはトンネルを通過していない（そうではないはずですか？）と言います。しかし、Debianではこれが当てはまるように見えます...しかし、なぜそうなるのかわかりません。ルーティングテーブルを見ると、tap0で送信しようとしているtracerouteパッケージは、eth0（デフォルトルート）に「再ルーティング」されていると思います。
今、これは私があなたの問題のために取るだろう推測に私を連れて来ます： IP転送 。 Ubuntuで無効になっているときにDebianボックスで有効になっている可能性がありますか？上記のリンクにアクセスすると（または、お気に入りの検索エンジンまたはUbuntuのマニュアルを使用して）、詳細情報（IP転送が有効になっているかどうかを確認する方法など）を見つけることができます。
UbuntuでSSHデーモンに到達できるということは、非常に近いことを示しています:)。だからあなたが何を意味するのかを知ることは重要かもしれません
「DebianサーバーのVPNクライアントIPは一般公開されていますが、Ubuntuサーバーではアクセスできません！」
Ubuntuマシンに「到達できない」ときに、何をしようとしていますか（つまり、どのサービスに接続しようとしていますか）。そのWebサーバーにアクセスしますか？このサービスはどのIPをリッスンしていますか？
Ubuntuには、リバースパスフィルタリングのデフォルトが異なる場合があります。 rp_filterのさまざまな/proc/sys/net/ipv4/conf/...を確認してください。
それでも問題が解決しない場合は、次のステップは、パケットがtcpdumpまたはwiresharkで出入りしているかどうかを確認することです。また、iptables -vLのファイアウォールが実際にないことを確認してください。
Rp_fileringがアクティブかどうかを確認します
sysctl -a | grep \\.rp_filter
= 1のインターフェースを探す
/etc/sysctl.confを編集し、
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.all.rp_filter=0
ここにそれについてのウェブの良いページがあります http://www.tolaris.com/2009/07/13/disabling-reverse-path-filtering-in-complex-networks/