web-dev-qa-db-ja.com

MULTI：クライアントからの不正な送信元アドレス-一時的な解決策はありますか？

Setup： openvpnクライアント/サーバーセットアップ（下部にある構成ファイル）を使用しており、サーバーで悪名高いMULTI: bad source address from client [192.168.x.x], packet droppedメッセージが表示されます。サーバーはパブリックIPアドレスを持ち、クライアントはNATの背後にあります。

以前に提案されたソリューションの短所：サーバー構成で定義されているclient-config-dirは現在空です。以前の投稿（こことopenvpnサポートフォーラム）では、DEFAULTという名前のファイルをclient-config-dirに適切なルールで追加するか、ユーザーごとのルールを追加して問題を解決することをお勧めします。

ただし、これらのルールはクライアントの場所に固有であるため、これは長期的な解決策ではないようです。そのため、192.168.x.0のクライアントが接続できるようにするルールを追加できます。ただし、NATに192.168.y.0を使用する別のネットワークから接続する場合は、新しいルールが必要になります。

質問：

  • 必要なルールを一般的な方法で記述できますか？
  • 誰かがこの問題が最初に発生する理由を説明できますか？

サーバー構成：

port 1234
proto tcp
dev tun

ca ca.crt
cert openvpn.crt
key openvpn.key
dh dh2048.pem

server 10.78.96.0 255.255.255.0
keepalive 10 120
comp-lzo
cipher CAMELLIA-128-CBC

user nobody
group nogroup  
persist-key
persist-tun
client-cert-not-required
plugin /usr/lib/openvpn/openvpn-auth-pam.so login

status openvpn-status.log

Push "redirect-gateway def1"
Push "remote-gateway 1.2.3.4"
Push "dhcp-option DNS 8.8.8.8"

client-config-dir ccd
verb 4

クライアント構成：

ca ca.crt
client
dev tun
proto tcp
remote 1.2.3.4 1234

auth-user-pass
script-security 2
keepalive 5 60
topology subnet
resolv-retry infinite
nobind
persist-key
persist-tun
ns-cert-type server
cipher CAMELLIA-128-CBC
comp-lzo
verb 4
vpnroutingopenvpn
10
m000

「最初にこの問題が発生する理由を誰かが説明できますか？」

公式OpenVPN FAQ で報告されている内容に基づいています。OpenVPNエンジン内のルーティングの問題が原因であると思います。

シナリオをより明確にするために、次の図を参照してみましょう。

ここであなたは見ることができます：

  • hEADQUARTER内部ネットワーク（10.0.1.0/24）に接続されたOpenVPN「サーバー」
  • リモートサイトで実行され、リモート192.168.1.0/24ネットワークに接続されたOpenVPN「クライアント」

また

  • openVPNトンネルが確立されていることを前提としています。
    • OpenVPN「サーバー」は、アドレス10.10.0.1の独自のtunインターフェースを介して到達可能です。 また、tunインターフェースで使用されるP2Pアドレスは10.10.0.2です（これは後の説明で重要なので、強調しましょう）
    • OpenVPN「クライアント」には、IP 10.10.0.2のtunインターフェイスがあります

さて、それを仮定しましょう：

  • openVPNの「クライアント」はデフォルトゲートウェイを再定義しているため、トンネル内ですべての発信IPトラフィックをリダイレクトできます。
  • OpenVPN「クライアント」ではIP_FORWARDINGが有効になっているため、内部LAN（192.168.1.0/24）からのパケットをルーティングできます（この点を強調します、それは私たちの議論にとって重要です）。

このようなシナリオが整ったら、R_PC1（192.168.1.2）がecho-r​​equestなどのパケットをL_PC1（10.0.1.2）に送信したときに何が起こるかを詳細に確認しましょう。

  1. r_PC1 NICを離れると、パケットはOpenVPNクライアントに到達します。
  2. OpenVPNクライアント（一般的なルーターとして機能するように構成されています）は、ルーティングテーブルに従ってルーティングします。デフォルトゲートウェイはトンネルなので、パケットをトンネルに送信します。
  3. パケットがOpenVPNサーバーのtunインターフェースに到達します。 OpenVPNはそれを「認識」し、10.0.1.2がそのLANサブネットに属するアドレスであることを（OpenVPNサーバー）が認識しているため、TUNからLANにパケットを「転送」します。
  4. パケットはL_PC1に到達します。

だからすべてが大丈夫です...

次に、L_PC1がR_PC1に返信するエコー応答で何が起こるかを確認しましょう。

  1. echo-r​​eplyはL_PC1 NICから離れ、OpenVPNサーバーのLANインターフェース（10.0.1.1）に到達します）;

OpenVPNサーバーがリモートサイトに到達できるようにするには、「静的ルート」を使用してルーティングを定義する必要があります。何かのようなもの：

route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.10.0.2

ゲートウェイとして使用されるP2Pアドレスに注意してください。

このような静的ルートはOSレベルで動作します。つまり、オペレーティングシステムがパケットを適切にルーティングする必要があります。 「192.168.1.0/24サブネットにアドレス指定されたすべてのトラフィックは、OSがP2Pアドレスを介して通信できるOpenVPNエンジンに転送される必要があります」のようなものを意味します。そのような静的ルートのおかげで、今...

  1. パケットはOSルーティングコンテキストを離れ、OpenVPNに到達します。 OpenVPNサーバーで実行されているOpenVPNインスタンス。したがって、この時点では、OSは何もする必要がなく、すべてのルーティング（VPN内）はOpenVPNサーバーソフトウェアに任されています。

それで、今、問題は次のとおりです：openvpnサーバーソフトウェアは、SRC_IP 10.0.1.2およびDST_IP 192.168.1.2を使用して、パケットのルートを決定することができます？

OpenVPNサーバーの設定に基づいて、192.168.1.0/24ネットワークについても192.168.1.2ホストについてもnothingを認識していることに注意してください。 not接続されたクライアントです。 notローカルクライアントです。など？ OpenVPNはまた、それがnot "OS-Router"であることを認識しているため、ローカルゲートウェイにパケットを送り返すことは望んでいません（そして、できます...）。したがって、ここでの唯一の選択肢は、エラーを発生させることです。まさに発生しているエラー

FAQの言語でそれを言うには、「...パケットをこのマシンにルーティングする方法がわからないため、パケットをドロップします...」。

どうすれば問題を解決できますか？

公式ドキュメント からわかるように、オプションirouteは正確に私たちのスコープに役立ちます：

--iroute network [netmask]
Generate an internal route to a specific client. The netmask 
parameter, if omitted, defaults to 255.255.255.255.
This directive can be used to route a fixed subnet from the server 
to a particular client, regardless of where the client is 
connecting from. Remember that you must also add the route to the 
system routing table as well (such as by using the --route 
directive). The reason why two routes are needed is that the 
--route directive routes the packet from the kernel to OpenVPN. 
Once in OpenVPN, the --iroute directive routes to the specific 
client.

だからあなたは必要です：

--iroute 192.168.1.0 255.255.255.0

openVPNクライアントが接続するときに（サーバーに）適用されます。たとえば、サーバーで定義されたアドホック構成ファイル（client-config-dirなど）を介して接続されます。

この問題がなぜnot上記のステップ2）で発生するのか不思議に思っている場合、私の理解はOpenVPNクライアントknows VPNトンネルであることを認識しているため、ルーティング方法デフォルトのゲートウェイです。

OpenVPNサーバーでも同じことはできません。デフォルトゲートウェイが一般的にnotオーバーライドされているためです。また、多数のOpenVPNクライアントを備えた単一のOpenVPNサーバーが存在する可能性があることを考慮してください。各クライアントはサーバーに到達する方法を知っていますが、サーバーは、不明なサブネットのゲートウェイとして機能しているクライアントを決定できますか？

あなたの最初の質問（必要なルールは一般的/一回限りの方法で書くことができますか？）については、申し訳ありませんが私はあなたの問題を解決していません。詳細を説明することはできますか？

12
Damiano Verzulli

似ているような問題がありましたが、あなたの問題と同じかどうかはわかりません。 openvpnクライアントからopenvpnサーバーのローカルネットワーク（サーバーの構成でルーティングされている）のコンピューターにpingを実行しようとしましたが、応答がなく、サーバーのopenvpnログに「不正な送信元アドレス」メッセージが表示されました。

それを解決するために、私は2つのことをしなければなりませんでした：

  1. サーバーでIP転送を有効にします。
  2. 私の場合、サーバーのローカルネットワークのゲートウェイはサーバー自体ではなくルーターであるため、サーバーのゲートウェイにVPNサブネットのルートを追加します。 pingを実行したコンピューターはゲートウェイを介して応答しようとしましたが、VPNサブネットに対して何を行うべきかまったくわかりませんでした。そこで、宛先にvpnサブネットを使用し、そのゲートウェイとしてopenvpnサーバーのIPを使用して、ルーターに静的ルートを追加しました。

それで解決しました。

1
aditsu