sshuttle 대 완전한 VPN: 그 방식이 실제로 무엇을 담당하는가
sshuttle은 전달 방식이 지원하는 것만 나릅니다. 먼저 TCP, DNS, UDP 적용 범위와 필요한 로컬 권한, 원격 도우미를 확인하세요.
sshuttle이 선택되는 이유는 SSH가 이미 동작하고 암호 기술이 익숙해 보이기 때문이지만, 그 논리는 적합성을 결정하는 유일한 질문을 건너뜁니다. 어떤 패킷이 기기를 떠나는지, 반대편에서 어느 계정이 그것을 나르는지, 도구가 얼마나 많은 로컬 권한을 요구하는지입니다. 이 세 답은 전달 방식에 따라 달라지므로 한 애플리케이션에서 동작한 구성이 다음 애플리케이션에서는 조용히 실패할 수 있습니다. 아래 설명은 애플리케이션이 실제로 필요로 하는 프로토콜에서 시작합니다.
애플리케이션에 필요한 프로토콜에서 시작하세요
sshuttle 2.0의 프로토콜 지원은 선택한 방식에 달려 있습니다. Linux의 NAT와 nft 방식은 TCP와 DNS를 처리하고 TPROXY는 일반 UDP를 추가합니다. 플랫폼과 방식마다 한계가 있으며 macOS는 전혀 다른 메커니즘으로 가로챕니다. 무엇이든 고르기 전에 설치된 버전, 선택한 방식, 애플리케이션에 필요한 프로토콜을 기록하세요.
따라서 동작하는 TCP 요청은 UDP 애플리케이션이나 모든 DNS 조회에 대해 매우 적은 것만 증명합니다. sshuttle은 TCP를 전체 IP 패킷 터널링이 아니라 스트림으로 다루므로 일반 VPN에서 빌려온 처리량 결론은 여기에 적용되지 않습니다. 실제로 실행하는 메커니즘을 실제로 가진 부하와 비교하세요.
| Approach | What it carries | What it needs locally |
|---|---|---|
| SSH local forward | One explicitly named TCP destination | Nothing beyond the SSH client |
| sshuttle, nft or nat method | TCP and DNS to the routed prefixes | Root or sudo for firewall rules |
| sshuttle, tproxy method | TCP, DNS and general UDP | Root or sudo, and kernel support |
| IP VPN | Routed IP traffic in a tunnel | A client with the required privileges |
클라이언트가 로컬에서 필요로 하는 것
문서화된 클라이언트 구성에는 root 또는 sudo가 필요합니다. 터널 인터페이스를 만드는 대신 로컬 가로채기 규칙을 설치하기 때문이며, 이 한 가지 사실이 보안 이야기를 바꿉니다. 그 권한을 가진 프로세스는 애플리케이션 하나가 아니라 기기 전체의 트래픽을 돌릴 수 있으므로 권한을 설치 세부 사항이 아니라 설계의 일부로 다루세요.
도구가 어떤 규칙을 설치했는지, 그리고 종료할 때 그것이 사라지는지 확인하세요. 가로채기 규칙을 남긴 채 중단된 세션은 운영자가 연결이 끊겼다고 믿은 훨씬 뒤에도 트래픽을 블랙홀로 보낼 수 있고, 증상은 남은 규칙이 아니라 네트워크 장애처럼 보입니다.
sudo sshuttle --method nft --dns 172.19.4.0/24
nft list ruleset | grep -i sshuttle
ip route첫 번째 명령은 일반적인 호출의 형태이며 실제로 필요한 접두사를 붙입니다. 두 번째는 도구가 무엇을 설치했는지 보여 주고, 세 번째는 터널 인터페이스가 나타나지 않았음을 확인하며 이것이 이 설계에서 기대되는 결과입니다.
원격 측이 실행하는 것
원격 측은 권한이 부여된 SSH 계정과 호환되는 Python 도우미 환경입니다. 제한된 셸에서 성공한 로그인이 그 도우미를 실행할 권한을 자동으로 주지는 않으며, 도우미를 실행할 수 있는 계정이 모든 대상 서비스에 자동으로 도달하지도 않습니다. 두 사실은 문제 해결 메모가 아니라 접근 요청에 속합니다.
호스트 신원 확인과 계정 인증을 보호하세요. 첫 연결을 위해 알 수 없는 호스트 키를 받아들이면 원격 측이 의도한 기기인지 확인하는 절차가 사라지며, 이는 단일 목적 전달보다 여기서 더 중요합니다.
원격 계정을 워크플로에 필요한 서비스로 제한하고 그 범위를 호스트 운영자와 협의하세요. 그들은 신뢰 관계의 일부이며 클라이언트 측 설정으로는 바뀌지 않습니다.
신뢰 경계가 어디에 있는가
SSH로 사설 API 연결을 전달한다고 해서 모든 API 작업이 허용되지는 않습니다. 애플리케이션 TLS와 애플리케이션 로그인은 여전히 적용되며 도구는 인증 없는 서비스를 안전하게 만들 수 없습니다. 원격 호스트에서의 추가 홉도 그 두 번째 연결이 원격 호스트의 정책을 따르므로 SSH 채널과 같은 보호 구간이 자동으로 되지는 않습니다.
경계를 한 문장으로 쓰면, 이 접두사로 가는 트래픽은 그 호스트의 이 계정을 통해 나갑니다. 그 문장에 예외 문단이 필요하다면 설계가 문서가 주장하는 것보다 많은 일을 하고 있으며 운영에 들어가기 전에 다시 볼 가치가 있습니다.
프로토콜별로 증명한 뒤 도구를 고르세요
필요한 각 프로토콜을 무해한 요청으로 시험하고 해석기 경로와 애플리케이션이 쓰는 주소 체계도 포함하세요. 시험에 연결 끊김도 넣어 애플리케이션의 허용된 실패 동작이 사고 때의 놀라움이 아니라 알려진 결과가 되게 하세요. 동작하는 동안 올바르게 전달한 세션은 끊긴 뒤에 무슨 일이 생기는지 말해 주지 않습니다.
명시적으로 이름 붙은 몇몇 서비스에는 평범한 로컬 전달이 소유와 감사에 더 쉽습니다. 그 방식에 맞는 애플리케이션 트래픽에는 sshuttle이 정당한 중간 지점을 제공합니다. 요구가 넓은 IP 연결이라면 VPN 설계가 정직한 답이며, 선택은 암호화 알고리즘 순위가 아니라 적용 범위와 운영 책임을 따릅니다.