느린 SOCKS 프록시를 기다리도록 OpenVPN을 구성하는 방법은 무엇입니까?

느린 SOCKS 프록시를 기다리도록 OpenVPN을 구성하는 방법은 무엇입니까?

저는 한 쌍의 Tor 게이트웨이와 OpenVPN 호스팅 가상 머신을 사용하여 Tor를 통해 라우팅되는 OpenVPN 연결을 실험하고 있습니다. 서버 측에서는 링크 로컬 포트가 연결된 게이트웨이 VM의 Tor 숨겨진 서비스 포트로 전달됩니다. 클라이언트 측에서 OpenVPN은 연결된 Tor 게이트웨이 VM의 sock 프록시를 통해 연결됩니다.

위 설정은 모든 Tor 게이트웨이 및 OpenVPN 호스팅 VM의 Debian 7에 적용됩니다. 나는 그것을 사용하고 있다호닉스, OpenVPN 2.3.2(2013-09-12 기반)로 업데이트되었습니다. 서버-클라이언트 핑은 약 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 ...)

이는 보고된 것과 동일한 오류입니다.데비안 버그 #657964openvpn 버전 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에 대한 방화벽 규칙을 만드는 것을 무시했습니다.

정말 당황스럽네요. 하지만 다른 사람들도 나와 같은 어리석은 실수를 저지를 경우를 대비해 이 질문은 열어두어야 한다고 생각합니다.

관련 정보