UDP OpenVPNサーバーがあります（TAPモードで実行されますが重要ではありません）。接続が正常に開始され、TLS-AUTH（HMAC）を通過しますが、そこで停止しています。サーバーログには次のものが重複しています。
Sun Jan 14 13:34:10 2018 us=104130 <CLIENT>:59975 UDPv4 READ [54] from [AF_INET]<CLIENT>:59975: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #1 ] [ ] pid=0 DATA len=0
Sun Jan 14 13:34:10 2018 us=104252 <CLIENT>:59975 UDPv4 WRITE [66] to [AF_INET]<CLIENT>:59975: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 pid=[ #1 ] [ 0 ] pid=0 DATA len=0
Sun Jan 14 13:34:12 2018 us=524356 <CLIENT>:59975 UDPv4 WRITE [54] to [AF_INET]<CLIENT>:59975: P_CONTROL_HARD_RESET_SERVER_V2 kid=0 pid=[ #2 ] [ ] pid=0 DATA len=0
Sun Jan 14 13:34:12 2018 us=650416 <CLIENT>:59975 UDPv4 READ [54] from [AF_INET]<CLIENT>:59975: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #2 ] [ ] pid=0 DATA len=0
....
しかし、クライアント側には次のものがあります。
2018-01-14 13:34:56 us=989963 UDPv4 WRITE [54] to [AF_INET]<SERVER>:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #2 ] [ ] pid=0 DATA len=0
2018-01-14 13:35:00 us=476619 UDPv4 WRITE [54] to [AF_INET]<SERVER>:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #3 ] [ ] pid=0 DATA len=0
2018-01-14 13:35:08 us=911249 UDPv4 WRITE [54] to [AF_INET]<SERVER>:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #4 ] [ ] pid=0 DATA len=0
2018-01-14 13:35:24 us=86742 UDPv4 WRITE [54] to [AF_INET]<SERVER>:1194: P_CONTROL_HARD_RESET_CLIENT_V2 kid=0 pid=[ #5 ] [ ] pid=0 DATA len=0
ここで何が起こっているのでしょうか？ファイアウォールがそれをブロックするわけではなく、他のサービスを使用してこのポートを介して正しく通信できます（netcatサーバーを実行すると双方向通信が正常に機能します）。
ベストアンサー1
openvpnメーリングリストのこの会話は私を正しい方向に導きました。
一方向リンクがあるようです。クライアントはサーバーと通信できますが、サーバーはクライアントと通信できません。だから、ある種のブロックがあったり、誤解を招くサーバー - >クライアントの方向に発生します。
たぶんクライアントファイアウォールですか？
(強調は私のもの)
local 192.168.1.X私の解決策は、サーバー構成ファイルにその行を追加することでした。 OpenVPNドキュメントによると：
--ローカルホスト
ローカルホスト名またはIPアドレス。指定した場合、OpenVPNはこのアドレスにのみバインドされます。指定しない場合、OpenVPN はすべてのインターフェイスにバインドされます。
明らかに、これはネットワークの問題ですが、基本的な問題を解決せずに解決できる問題です。私にとって問題は、ブリッジインターフェイスとタブインターフェイスを設定する方法です。私は台無しにしました。 OpenVPNは、応答パケットを宛先にルーティングできないインターフェイスを介して再ルーティングしようとしました。したがって、バインドする特定のインターフェイスを指定すると、指定されたIPを使用してそのインターフェイスからのみパケットを送信できます。さらにbridge-start、マルチタップインターフェイス（すべての追加ブリッジはルーティングできないブラックホール）を生成しないようにスクリプトを変更することでこの問題を解決することができました（もはやローカル設定フラグは不要です）。ローカルアドレスを使用しても、内部ネットワーク外部/ NATを介してまだうまく機能します。