web-dev-qa-db-ja.com

TUNデバイス(C ++バックエンド)からデフォルトゲートウェイにトラフィックを転送する

次の問題は、私が問題を抱えているより大きな解決策のほんの一部です。他のすべての要素はこれまでのところ機能しているように見えるので、私が問題を抱えている非常に小さな部分について説明しようと思います。

tun0(トンネリングインターフェイス)とeth0を備えたLinuxマシンを持っています-)(魔女はインターネットへの私のデフォルトゲートウェイです)。

目標:私の目標は、tun0から着信するパケットを受信し、それらをデフォルトゲートウェイに転送することです。したがって、実際には非常に単純なNATの場合、物理インターフェイスを偽造するtun0とインターネットを「共有」したい場合です。

Tunはを使用して作成されました

Sudo openvpn --mktun --dev tun0 --user USER
Sudo ip addr add 10.2.0.1/24 dev tun0
Sudo ip link set tun0 up

これで、稼働し、pingを実行できます。さらに、このTUNデバイスに接続するC++アプリケーションを使用して、読み取りと書き込みを行うことができます。 (fti:これは私が従ったチュートリアルです: http://backreference.org/2010/03/26/tuntap-interface-tutorial/

8.8.8.8に対して行われた正しいICMP(ping)要求をC++のバイト配列にダンプしました。今、私のプログラムを使用して、それをtun0デバイスに書き込みます。 ICMPリクエストには

  • ソース(10.2.0.10)-カーネルは戻るルートを認識します(同じサブネット)
  • 宛先(8.8.8.8)-GoogleのDNS
  • 正しいチェックサムなど(Wireshark/TSharkではtun0に正しく表示されます)

次に、次のルートがあります。

iptables -F # flush
iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE
iptables --append FORWARD --in-interface tun0 -j ACCEPT

そして、ここで私は立ち往生しています:(パケットはデフォルトのgwに転送されません(tsharkは受信したtun0でのみそれを見るので、正しいと思います)

何が欠けていますか?おそらくいくつかの代替アプローチ(ただし、tunデバイスを使用して実行する必要があり、それにr/wできる必要があります)。追加情報:

  • 転送が有効になっています(/ proc/sys/net/ipv4/ip_forward)
  • 8.8.8.8はeth0を介して到達可能です(ローカルから)
  • デフォルトゲートウェイは正しい(ISPからeth0経由)
  • rp_tables(echo 0>/proc/sys/net/ipv4/conf/eth5/rp_filter)をオフにしてみました
  • と他の多くの...

ヒントを事前に感謝します!

10
Marcin Górski

別の解決策はbridgeを使用することです。したがって、tun0をeth0とブリッジでき、natやtun0にipを設定する必要はなく、現在使用しているeth0の同じサブネットと同じゲートウェイからIPを配置するだけです。クライアントのトンネルインターフェース上。

ブリッジを設定するためのコマンド:

# brctl addbr br0
# brctl addif br0 eth0 tun0

www.tldp.org/HOWTO/BRIDGE-STP-HOWTO/set-up-the-bridge

Brctlを使用するには、bridge-utilsパッケージをインストールする必要があります。
ディストリビューションがUbuntuの場合:aptitude install bridge-utils

1
Arash

私は最近この問題に遭遇し(質問で言及された同じ記事に続いて)、少しいじった後、次のコマンドがtunデバイスのパケットのローカル転送を有効にすることを発見しました。

echo 1 > /proc/sys/net/ipv4/conf/tun0/accept_local

私はそれが非常に遅いことを知っています、私は同じ問題に直面している誰もが何らかの助けを得ることができるようにここに投稿しています。

1
Swarup Sengupta