SSH 클라이언트를 통해 원격 Pi에 SOCKS 프록시 제공하기

원격 동적 포워딩은 SOCKS 리스너를 Pi에 두고 이후 연결을 노트북의 승인된 VPN 경로에서 시작합니다. 두 번째 SSH 서버는 필요 없습니다.

SOCKS 프록시는 네트워크 접근이 이미 있는 곳에서 실행해야 한다고 가정하기 쉽습니다. OpenSSH는 리스너를 전혀 다른 곳에 둘 수 있습니다. 원격 동적 포워딩은 원격 호스트에서 SOCKS 포트를 열고, 각 연결을 노트북의 승인된 VPN 경로를 나르는 로컬 SSH 클라이언트에서 시작합니다. Pi는 범위가 제한된 프록시를 얻고, 당신의 터널이나 권한을 물려받지는 않습니다.

리스너와 연결이 시작되는 쪽은 다를 수 있습니다

일반적인 ssh -D 1080는 리스너를 자신의 컴퓨터에서 실행하고 거기서 연결을 내보냅니다. 원격 동적 포워딩은 이를 뒤집어, 리스너는 원격 호스트에 나타나고, 받아들인 모든 연결은 로컬 쪽에서 열립니다. OpenSSH 클라이언트 매뉴얼은 고정된 목적지가 없는 -R를 정확히 이런 SOCKS4/5 구성으로 설명합니다.

노트북에서 실행하는 지원되는 명령은 다음과 같으며, 계정과 호스트, 포트는 자리 표시자로 취급합니다:

ssh -NT -S none -o ExitOnForwardFailure=yes \
  -o PermitRemoteOpen=app.corp.example:443 \
  -R 1080 [email protected]

여기서 세 가지가 유용한 일을 합니다. -S none는 세션을 공유 컨트롤 마스터에서 떨어뜨려 두고, ExitOnForwardFailure는 반쯤 열린 세션을 남기는 대신 빠르게 실패하며, PermitRemoteOpen는 원격 리스너가 닿을 수 있는 범위를 제한합니다. 승인된 Pi 계정을 사용하고, 이 중 무엇이든 추가하기 전에 호스트 키를 검증하세요.

원격 리스너가 실제로 노출하는 것

리스너에 의존하기 전에 서버의 포워딩 정책을 확인하세요. GatewayPorts no에서는 원격 포워딩이 loopback에 묶여 있고, 이것이 원하는 노출입니다. 와일드카드 포워딩을 강제하는 서버는 같은 포트를 모든 인터페이스에 공개하므로, 개인용 프록시가 로컬 네트워크에서 닿을 수 있는 것이 됩니다.

loopback도 사용자별 경계가 아닙니다. Pi의 다른 프로세스가 포트를 안다면 127.0.0.1:1080에 연결할 수 있으므로, Pi의 로컬 계정과 그 위에서 실행되는 모든 것은 접근 설계의 일부입니다. 이는 목적지 목록을 좁게 유지할 이유이지, 정책 확인을 건너뛸 이유가 아닙니다.

허용된 목적지는 접근하려는 애플리케이션에 맞게 구체적으로 유지하세요. 무관한 프로그램을 돌리기 위해 무제한 포워딩으로 바꾸면, 처음 시작한 문제에서 훨씬 멀리까지 경로가 넓어집니다. 목적지 목록은 그 세션이 무엇을 위한 것인지도 기록하므로 나중에 감사하는 사람에게 도움이 됩니다. 사용한 계정 옆에 적어 두세요.

애플리케이션 하나를 프록시로 보내기

Pi에서 프록시를 이해하는 클라이언트가 그다음 요청을 보낼 수 있습니다. socks5h 접두사는 목적지 이름을 프록시에 넘기므로, 조회와 연결이 모두 노트북 쪽에서 일어나고, PermitRemoteOpen에 지정한 목적지와 일치합니다:

curl --proxy socks5h://127.0.0.1:1080 \
  --noproxy '' https://app.corp.example/

일반적인 인증서 검증과 애플리케이션 자체의 인증은 그대로 두세요. 프록시는 TCP 연결이 만들어지는 위치를 바꿀 뿐, 인증이 없는 서비스를 안전하게 만들지 않으며 자체 서명 엔드포인트를 신뢰할 수 있는 것으로 바꾸지도 않습니다.

노트북에는 여전히 자체 경로와 SSH 서버, 애플리케이션 양쪽에 대한 리졸버 접근이 필요합니다. 그 SSH 클라이언트의 트래픽은 승인된 VPN 정책으로 선택되어야 하고, 분할 터널 예외는 그 트래픽을 시험한 경로와 다른 경로로 보낼 수 있습니다.

경로를 증명하고 닫기

리스너가 예상한 곳에 있고 의도한 목적지만 응답하는지 확인하세요:

$ ss -ltnp | grep 1080
LISTEN 0 128 127.0.0.1:1080 0.0.0.0:*
$ curl -sS -o /dev/null -w '%{http_code}\n' \
    --proxy socks5h://127.0.0.1:1080 https://app.corp.example/

ExitOnForwardFailure는 포워딩이 설정되었음을 증명할 수 있지만, 그 아래에서 애플리케이션 로그인이 성공하는지까지 보증하지는 못합니다. 포트만이 아니라 애플리케이션을 시험하세요. 연결을 받아들인 뒤 모든 요청을 실패시키는 리스너는 보통 터널이 실패한 것이 아니라 목적지 이름이나 노트북의 경로가 잘못되었다는 뜻입니다.

이 구성은 TCP만 나릅니다. UDP, ICMP, 프록시 설정을 무시하는 프로그램은 여기서 빠지고, 포워딩은 SSH 세션이 끝나는 순간 끝납니다. 끝나면 그 세션을 중지하고 애플리케이션에 추가한 프록시 설정을 제거하세요.

영구적인 접근에는 대신 네트워크 소유자가 지원하는 등록이나 관리형 게이트웨이를 사용하세요. VPN의 기기나 리소스 제한을 우회하려는 목적으로 리버스 프록시를 쓰는 것은 잘못이며, 그 제한 안에서 쓴다면 명시적 한도를 가진 승인된 애플리케이션 경로 하나가 늘어날 뿐입니다.

관련 글