OpenVPN용 SOCKS5 프록시: TCP 터널인가, 앱을 프록시하는 것인가?
프록시는 데이터그램이 아니라 스트림을 중계합니다. socks-proxy 뒤의 TCP 터널과 redsocks 리디렉션을 비교하고 각 설계가 어디서 먼저 무너지는지 확인하십시오.
프록시를 통한 외부 연결만 허용하는 네트워크가 바로 작동하던 프로필이 갑자기 죽는 곳입니다. 프록시 주소는 그 실패에서 가장 흥미롭지 않은 변수입니다. 모든 것을 결정하는 것은 프록시가 중계할 트래픽의 형태인데, 이 프록시들은 바이트 스트림을 전달하고 UDP 터널은 그런 것이 아니기 때문입니다. 그래서 두 가지 아키텍처가 남고, 둘은 서로 다른 지점에서 깨집니다.
하나의 제약이 설계를 결정합니다
SOCKS5는 실제로 UDP 연관 모드를 규정합니다. 그럼에도 OpenVPN 클라이언트의 프록시 지원은 스트림을 중심으로 만들어져 있습니다: socks-proxy는 TCP 프로필용으로 문서화되어 있고, HTTP CONNECT 프록시에는 데이터그램 경로가 전혀 없습니다. 문서 한 줄이 구성 파일을 건드리기 전에 아키텍처를 결정합니다.
따라서 질문은 어떤 프록시를 고르느냐가 아닙니다. 터널이 스트림이 되는지, 아니면 데이터그램으로 남아 다른 무언가가 프록시 처리를 흡수하게 하는지입니다.
옵션 A: 터널을 스트림으로 만들기
TCP 리스너가 있는 서버와 프록시를 지정하는 클라이언트 프로필이 필요합니다. 두 부분 모두 필요하며, 사람들이 잊는 것은 서버 쪽입니다:
proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080마지막 줄을 http-proxy proxy.internal 8080로 바꾸고, 프록시가 HTTP를 말할 때 자격 증명 파일을 요구하면 추가하십시오. 프록시는 VPN 포트로 CONNECT를 수행할 의사가 있어야 하고, 서버는 TCP로 응답해야 합니다; UDP만 듣는 리스너는 그 시도를 무시합니다. 443을 고르는 것은 많은 제한 네트워크가 그것 외에는 거의 허용하지 않기 때문에 실용적인 선택입니다.
비용은 TCP 위에 TCP를 쌓는 것입니다. 손실된 외부 세그먼트 하나가 그 연결을 공유하는 모든 내부 스트림을 멈추게 하므로, 보통 독립적이었을 복구가 공유됩니다. 설정도 더 오래 걸리고, 불안정한 외부 경로는 느린 터널이 아니라 불안정한 터널이 됩니다.
옵션 B: 터널을 그대로 두기
터널이 UDP에 남아야 한다면, 터널은 무언가를 구성하는 곳이 아닙니다. 대신 애플리케이션의 외부 TCP가 로컬 SOCKS 리스너로 리디렉션되고, 애플리케이션은 프록시가 있다는 것을 결코 알지 못합니다. Linux에서는 보통 redsocks와 nat 테이블의 NAT REDIRECT 규칙입니다.
다시 TCP만입니다. privoxy 같은 HTTP 전용 프록시는 임의 프로토콜을 중계할 수 없고, 이 설계는 애플리케이션에 데이터그램 지원도 추가하지 않습니다.
소프트웨어가 지원하는 곳에서는 각 애플리케이션에 프록시를 직접 알려주는 편이 보통 낫습니다. 감사하기 쉽고, 실제로 볼 수 있는 지점에서 실패합니다.
각 옵션이 실패하는 지점
옵션 A는 서버에 TCP 리스너가 없을 때, 프록시가 CONNECT 대상을 거부할 때, 또는 외부 스트림이 터널에 필요한 수준 아래로 제한될 때 실패합니다. 처음 두 가지는 프록시 로그에 항목을 남기고, 세 번째는 연결이 설정된 뒤 뭔가 잘못된 느낌을 남깁니다. 프로필을 편집하기 전에 권한 문제와 용량 문제를 구분해 주는 그 로그를 읽으십시오. 완료된 CONNECT는 조사를 터널 안으로 옮깁니다.
옵션 B는 데이터그램이 필요한 모든 것, 프록시가 이해하지 못하는 프로토콜, 그리고 리디렉션 규칙은 있지만 라우팅이 트래픽을 그 옆으로 보내는 호스트에서 조용히 실패합니다.
어느 옵션도 장치 요구 사항을 바꾸지 않습니다. 패킷은 커널이 라우팅하기 전에 여전히 TUN 또는 TAP 노드가 필요하므로 프로세스는 여전히 /dev/net/tun에 대한 권한이 필요합니다. 래퍼는 그 노드가 열린 뒤에 무슨 일이 일어나는지를 바꿀 뿐, 그것이 필요한지 여부를 바꾸지 않습니다.
어떤 경로를 만들었는지 증명하기
트레이 아이콘이 아니라 소켓을 보십시오. VPN 프로세스는 프록시 주소에 대한 설정된 연결을 유지해야 하고, 프록시는 도달하라는 대상을 기록했어야 합니다:
ss -tnp | grep openvpn그다음 터널만 서비스할 수 있는 목적지로, 터널 리졸버만 응답할 수 있는 이름으로 이동하십시오. 죽은 터널과 완료된 프록시 연결은 보통 원격 쪽이 프로필에 명시된 전송 방식을 제공한 적이 없다는 뜻입니다.
전송 방식과 연결을 수락한 프록시를 오래 남는 곳에 기록하십시오. 같은 프로필이 다른 네트워크에서 실패할 때, 그 메모는 몇 초 만에 프록시를 배제하거나 확인해 줍니다.