私は、一対のTorゲートウェイとOpenVPNホスティング仮想マシンを使用して、Torを介してルーティングされるOpenVPN接続を試しています。サーバー側では、リンクローカルポートが接続されているゲートウェイVMのTor隠しサービスポートに転送されます。クライアント側では、OpenVPN は接続された Tor ゲートウェイ VM の sock プロキシを介して接続されます。
上記の設定は、すべてのTorゲートウェイとOpenVPNホスティングVMのDebian 7に適用されます。私はそれを使用していますホニックス、OpenVPN 2.3.2（2013-09-12ベース）に更新されました。サーバークライアントのpingは約1200msです。
ただし、pfSense 2.1をTorゲートウェイとして使用し、サーバー側のOpenVPNを使用してVMをホストしている場合、この設定は正しく機能しません。 pfSense 2.1にはOpenVPN 2.3.2（2013-07-24に構築されています）も含まれています。 Debian および pfSense クライアントの場合、次のように表示されます。
TCP connection established with [AF_INET]192.168.0.10:9152
recv_socks_reply: TCP port read timeout expired: Operation now in
progress (error ...)
これは報告されたのと同じエラーです。Debian のバグ #657964" openvpn バージョン 2.2.1-3: "openvpn: SOCKS プロキシを使用して VPN に接続できません。"これも報告されています。OpenVPNのバグ＃328openvpn バージョン 2.3.2 の場合: 「プロキシ サーバーが遅くなると、openvpn クライアントが再試行する代わりに放棄します。」
ただし、これは同じエラーではない可能性があります。ここでの問題は、クライアントTor SOCKSプロキシの待ち時間ではなく、Tor隠しサービスを介して転送されるOpenVPNサーバーポートの待ち時間です。または両方。
とにかく、pfSense 2.1では、このクライアントエラーが原因でOpenVPN 2.3.2サーバーが失敗しますが、Debian 7ではそうではないことがわかりました。おそらく、Debian 7リポジトリの最新パッケージには、pfSense 2.1がビルドされてからリリースされたバグ修正が含まれています。
遅いSOCKSプロキシを待つようにOpenVPNを設定する方法は？
答え1
Op（つまり、私）は取りませんでした。このOpenVPN FAQ真剣に:
One of the most common problems in setting up OpenVPN is that the two
OpenVPN daemons on either side of the connection are unable to
establish a TCP or UDP connection with each other.
This is almost [always] a result of:
...
A software firewall running on the OpenVPN server machine itself is
filtering incoming connections on port 1194 [here 5000-5007]. Be aware
that many OSes will block incoming connections by default, unless
configured otherwise.
OpenVPNには問題ありません。
TorゲートウェイpfSense VMの隠しサービスプロキシへのアクセスを提供するために、OpenVPNサーバーを実行しているpfSense VMでWANのファイアウォールルールを作成することを無視しました。
本当に恥ずかしいですね。しかし、他の人も私のような愚かなミスを阻止する場合に備えて、この質問は開いておくべきだと思います。