Redsocks는 루프백에서 수신하지만 VPN 트래픽은 도착하지 않는다

루프백에만 바인딩된 리스너는 tun0에서 리디렉션된 트래픽을 결코 보지 못합니다. 리디렉션 대상과 소켓 바인드를 확인하고, 바인드를 고친 뒤 실제 클라이언트에서 시험하십시오.

터널이 올라오고, 클라이언트는 게이트웨이에 ping을 보낼 수 있지만, 프록시 경로를 지나는 모든 웹 요청은 죽습니다. redsocks 프로세스가 실행 중이고 포트가 수신 중이라, 게이트웨이 자체에서는 서비스가 건강해 보입니다. 실패하는 것은 전달 단계입니다: 터널에서 리디렉션된 패킷이 당신이 띄운 소켓에 도착하지 않습니다. 바인드 주소와 리디렉션 대상은 일치해야 하는데, 보통 둘 중 하나만 확인합니다.

리디렉션된 패킷이 실제로 도착하는 곳

게이트웨이의 투명 프록시는 PREROUTING의 nat 테이블에서 REDIRECT를 사용해 들어오는 연결의 목적지를 로컬 포트로 다시 씁니다. 다시 쓴 목적지는 패킷이 도착한 인터페이스에서 보이는 로컬 주소이며, 다른 곳에서 시작된 프로세스의 루프백 주소가 아닙니다. 127.0.0.1에만 바인딩된 리스너는 이미 호스트에서 로컬이었던 연결을 받아들이는데, 터널 트래픽이 실패하는 동안 계속 동작하는 경우가 바로 이것입니다. 클라이언트 자신의 루프백은 세 번째 주소이며 게이트웨이 규칙의 대상이 되는 일은 결코 없습니다.

그러므로 상위 자격 증명을 건드리기 전에 규칙이 어느 로컬 주소로 다시 쓰는지, 프록시 소켓이 어느 주소에 바인딩되어 있는지 두 가지 사실을 확정하십시오.

리스너와 리디렉션 규칙을 함께 읽기

소켓 테이블과 nat 규칙은 아무도 소유하지 않은 포트를 가리키는 규칙이 잘못된 주소를 가리키는 규칙과 똑같이 보이므로 한 번에 출력하십시오. sudo ss -ltnp | grep redsocks 은 바인드 주소와 소유 프로세스를 보여 줍니다. sudo iptables -t nat -S PREROUTING 은 REDIRECT 대상을 보여 주고, sudo iptables -t nat -L PREROUTING -v -n 는 그것에 일치한 것이 있는지 보여 줍니다.

REDSOCKS라는 이름의 사용자 체인으로 점프하는 것은 그 체인이 존재하고 의도한 제외와 REDIRECT 동작을 담고 있지 않으면 아무것도 성취하지 못합니다. 이름이 일을 한다고 가정하지 말고 점프하는 체인을 sudo iptables -t nat -S REDSOCKS 로 읽으십시오.

그다음 두 값을 비교하십시오. 규칙이 포트 12345의 게이트웨이 주소로 리디렉션하는데 리스너가 127.0.0.1:12345 를 보고한다면, 그 불일치가 추가 진단 없이 실패를 설명합니다.

좁게 바인딩하고, 그다음 도달할 수 있는 범위를 제한하십시오

상위 샘플 구성이 리스너를 루프백에 두는 데는 이유가 있습니다: 투명 프록시는 거기에 도달할 수 있는 누구의 대신이라도 연결을 받아들입니다. 바인드를 0.0.0.0으로 바꾸면 전달은 고쳐지지만 동시에 모든 인터페이스에서 포트가 열리며, 이는 보안 변경이지 중립적 수리가 아닙니다. 리디렉션이 겨냥하는 특정 로컬 주소에 바인딩하는 편을 택하고, 신뢰할 수 없는 인터페이스에서는 포트를 닫아 두십시오. 더 넓은 바인드가 불가피하다면 터널 원본 범위와 게이트웨이 자체의 로컬 트래픽만 허용하는 호스트 방화벽 규칙을 추가하십시오.

공용 인터페이스에서 포트를 여는 것은 다시 쓴 뒤 연결이 로컬에서 끝나기 때문에 리디렉션된 VPN 트래픽에 결코 필요하지 않습니다. 로컬 리디렉션을 동작시키려고 프록시를 인터넷에 노출하지 마십시오.

클라이언트에서 새 연결로 증명하십시오

게이트웨이의 셸이 아니라 실제 VPN 클라이언트에서 새 TCP 연결로 시험하십시오. 클라이언트의 curl -sS -o /dev/null -w '%{http_code}\n' http://example.com 는 리디렉션된 경로를 처음부터 끝까지 실행합니다.

그다음 신뢰할 수 없는 네트워크에서 리스너로의 직접 연결이 여전히 거부되는지, 프록시 자체의 상위 연결이 같은 규칙에 다시 붙잡히지 않는지 확인하십시오. 재귀적 포획은 자기 자신에 연결하고 요청을 끝내지 않는 프록시로 나타납니다. 프록시의 목적지를 제외 집합에 추가하거나, 체인이 건너뛰도록 그 발신 패킷을 표시하십시오.

마지막으로 이 경로가 다루지 않는 것을 기억하십시오. 일반적인 redsocks TCP 리디렉션은 UDP, QUIC 또는 DNS를 SOCKS 트래픽으로 바꾸지 않으며, 사설 목적지는 보통 명시적 제외가 필요합니다. 성공한 로컬 시험은 문제가 아니었던 루프백 경로만 증명합니다.

관련 글