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

セットアップ： 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が接続できるようにするルールを追加できます。ただし192.168.y.0、NAT を使用する別のネットワークから接続する場合は、新しいルールが必要になります。

質問：

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

サーバー構成：

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

あなたは尋ねました：「この問題がなぜ最初に起こるのか誰かが説明できますか？」

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に返信するエコー応答で何が起こるかを確認しましょう。

5. エコー応答は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エンジンに転送される必要がある」のようなものを意味します。そのような静的ルートのおかげで、今...

6. パケットは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ホストについては何も認識しないことに注意してください。それはだていない接続されたクライアント。それはだないローカルクライアント。など？OpenVPNは、それが「OSルーター」ではないことも知っているため、ローカルゲートウェイにパケットを送り返すことは望んでいません（そして、できます...）。したがって、ここでの唯一の選択肢は、エラーを発生させることです。まさに発生しているエラー

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など）を介して接続するときに（サーバーに）適用されます。

あなたはこの問題がない理由だろべきではない以上、私の理解は、OpenVPNのクライアントがいることである）ステップ2で起こる知っているか、それはVPNトンネルは、デフォルトゲートウェイであることを知っている原因ルートそれ」へ。

OpenVPNサーバーでも同じことはできません。なぜなら、デフォルトゲートウェイは通常、上書きされないためです。また、多数のOpenVPNクライアントを備えた単一のOpenVPNサーバーを使用できると考えてください。各クライアントはサーバーに到達する方法を知っていますが、サーバーは、不明なサブネットのゲートウェイとして機能しているクライアントをどのように決定できますか？

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

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

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

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

それで解決しました。