web-dev-qa-db-ja.com

Linux、Quagga、OpenVPNでのルーティングの問題

セットアップ

中央ルーターとして機能するOpenVPNサーバーがあります。 「トポロジサブネット」コマンドで設定されます。クライアントはDebianLinuxノードであり、それぞれに1つ(または複数)のサブネットが直接接続されています。

目的は、VPNに接続されているすべてのクライアントが、他のクライアントの背後に接続されているサブネットにアクセスできるようにすることです。

ルーティング情報を広めるために、クライアントとサーバーにQuaggaをインストールしました。これは、OSPFデーモンを使用して正常に機能します。ルーティングは、すべてのクライアントとサーバーでも有効になっています。

ルーティングテーブル

サーバー上のルーティングテーブルは次のとおりです。

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.2.10.1       10.8.0.4        255.255.255.255 UGH   20     0        0 tun0
192.168.100.0   10.8.0.4        255.255.255.0   UG    20     0        0 tun0
192.168.1.0     10.8.0.4        255.255.255.0   UG    20     0        0 tun0

アクセスしたいサブネットは192.168.100.0/24です。問題のゲートウェイは完全に正常に応答し、問題なく接続できます。

これは役に立たないと思いますが、ここにクライアントルーティングテーブルの一部があります:

10.2.10.1       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
192.168.100.0   0.0.0.0         255.255.255.0   U     0      0        0 eth1
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0

物事が南に向かい始めるところ

サーバー(10.8.0.1)から192.168.100.0/24サブネット内の任意のホスト(VPNクライアントインターフェイスを含む)へのpingが失敗します。 VPNクライアントでtunインターフェイスをtcpdumpすると、関連するパッケージが表示されません。 VPNサーバーでtunインターフェイスをtcpdumpすると、問題のパッケージが送信されているのがわかります。

本当にエッジの効いたことは、192.168.100.0サブネット内の有効なIPにtracerouteしたときに、ホップが検出されないことです(ホップは1つだけである必要があります)。ネクストホップ(10.8.0.4)に直接tracerouteを実行すると、正常に応答します。

これは非常に複雑な問題なので、はっきりしていることを心から願っています。ご要望に応じて、追加情報を提供させていただきます。

1

最終的に「client-config-dir」を使用して、「iroute」コマンドを使用して各クライアントの背後のルートを指定できるようになりました。

その後、VPNサーバーにこれらすべてのサブネットのルートを他のすべてのクライアントにプッシュさせましたが、正常に機能しました。

0

私が奇妙だと思うのは、クライアントのルーティングテーブルがどこも指していないことです(0.0.0.0)。ローカルネットワークでは問題ありませんが、トンネルを通過する10.2.10.1では問題になる可能性があります。

0
Gopoi

VPNトンネルを横切るデフォルトルートは、クライアントが他のクライアントにルーティングできるようにするのに十分であり(VPNコンセントレーターが許可している限り)、ルーティングデーモンを実行する必要はないと思いました。個々のクライアント。

ルーティングテーブルを見ると、ルーティングアップデートで運ばれる「ネクストホップ」がクライアントに到達できず、ルートを無視する代わりに、不明なネクストホップでインストールされることが問題であると思われます。

Quaggaを非アクティブ化し、代わりにVPNトンネルを通過するデフォルトルートを使用するとどうなりますか?

0
Vatine