sshuttle - 클라우드의 온라인

프로그램:

이름

셔틀 - 셔틀 문서

개요

셔틀 [옵션] [-r [사용자 이름@]sshserver[:포트]]서브넷 ...>

기술

셔틀 컴퓨터에서 원격 서버로 VPN 연결을 만들 수 있습니다.
해당 서버에 python 2.3 이상이 있는 한 ssh를 통해 연결할 수 있습니다.

작동하려면 로컬 시스템에 대한 루트 액세스 권한이 있어야 하지만 일반 계정을 가질 수 있습니다.
서버에.

실행하는 것이 유효합니다 셔틀 단일 클라이언트 시스템에서 동시에 두 번 이상,
매번 다른 서버에 연결하므로 한 번에 둘 이상의 VPN에 연결할 수 있습니다.

라우터에서 실행하는 경우 셔틀 전체 서브넷의 트래픽을 VPN으로 전달할 수 있습니다.

옵션

서브넷
VPN을 통해 라우팅할 서브넷 목록(형식) abcd[/너비]. 유효한
예는 1.2.3.4(단일 IP 주소), 1.2.3.4/32(1.2.3.4와 동일),
1.2.3.0/24(24비트 서브넷, 즉 255.255.255.0 넷마스크 사용) 및 0/0('그냥
VPN을 통해 모든 것을 라우팅').

-엘, --listen=[ip:]포트
이 IP 주소와 포트 번호를 투명 프록시 포트로 사용하십시오. 기본적으로
셔틀 사용 가능한 포트를 자동으로 찾고 IP 127.0.0.1에서 수신 대기합니다.
(localhost)이므로 재정의할 필요가 없으며 연결만 프록시됩니다.
외부 시스템이 아닌 로컬 시스템에서. 수락하고 싶다면
네트워크의 다른 컴퓨터에서 연결(예: 실행 셔틀 라우터에서)
커널에서 IP 전달을 활성화한 다음 다음을 사용하십시오. --듣다 0.0.0.0:0.

tproxy 방법의 경우 이것은 IPv6 주소일 수 있습니다. 다음과 같은 경우 이 옵션을 두 번 사용하십시오.
IPv4 및 IPv6 주소를 모두 제공하려면 필요합니다.

-시간, --자동 호스트
원격 호스트 이름을 검색하고 로컬 업데이트 은 / etc / 호스트 일치하는 파일
VPN이 열려 있는 동안 항목. 이것은 시스템을 변경하는 것보다 낫습니다.
DNS(/ 기타 / resolv.conf에) 설정, 여러 가지 이유로. 먼저 호스트 이름이 추가됩니다.
도메인 이름을 첨부하지 않고도 SSH 서버 당신의 경우 걱정하지 않고
로컬 도메인이 원격 도메인과 일치합니다. 둘째, 만약 당신이 셔틀 하나 이상으로
한 번에 VPN, 어쨌든 한 번에 둘 이상의 DNS 서버를 사용하는 것은 불가능하지만,
셔틀 올바르게 병합 은 / etc / 호스트 실행 중인 모든 사본 사이의 항목. 셋째, 만약
VPN을 통해 몇 개의 서브넷만 라우팅하고 있으므로
다른 모든 작업에는 로컬 DNS 서버를 사용합니다.

-N, --auto-nets
명령줄에 제공된 서브넷 외에도 서버에 다음을 요청하십시오.
우리가 라우팅해야 한다고 생각하는 서브넷을 자동으로 라우팅합니다. 제안
서버의 라우팅 테이블에서 자동으로 가져옵니다.

--DNS 로컬 DNS 요청을 캡처하고 원격 DNS 서버로 전달합니다.

-파이썬
원격 파이썬 인터프리터의 이름/경로를 지정합니다. 기본값은 그냥
파이썬, 이는 원격 시스템의 기본 파이썬 인터프리터를 사용하는 것을 의미합니다.
길.

-NS, --remote=[사용자 이름@]sshserver[:포트]
연결에 사용할 원격 호스트 이름 및 선택적 사용자 이름 및 ssh 포트 번호
원격 서버에. 예를 들어 example.com, [이메일 보호],
[이메일 보호]:2222 또는 example.com:2244.

-NS, --exclude=서브넷
이 서브넷을 전달에서 명시적으로 제외합니다. 이 옵션의 형식은
같은 옵션. 둘 이상의 서브넷을 제외하려면 다음을 지정하십시오. -x
옵션을 두 번 이상. 다음과 같이 말할 수 있습니다. 0/0 -x 1.2.3.0/24 앞으로
예를 들어 VPN을 통한 로컬 서브넷을 제외한 모든 것.

-NS, --exclude-from=파일
파일에 지정된 서브넷을 한 줄에 하나씩 제외합니다. 있을 때 유용
제외할 서브넷이 많습니다.

-V, --말 수가 많은
세션에 대한 자세한 정보를 인쇄하십시오. 이 옵션은 두 번 이상 사용할 수 있습니다.
더 자세한 정보를 위해. 기본적으로, 셔틀 오류 메시지만 인쇄합니다.

-이자형, --ssh-cmd
원격 서버에 연결하는 데 사용할 명령입니다. 기본값은 그냥 SSH. 사용
이것은 ssh 클라이언트가 비표준 위치에 있거나 추가 정보를 제공하려는 경우
예를 들어, ssh 명령에 대한 옵션 -e '쉬 -V'.

--시드 호스트
초기화에 사용할 호스트 이름의 쉼표로 구분된 목록 --자동 호스트 주사
연산. --자동 호스트 로컬 목록에 대해 로컬 SMB 서버를 폴링하는 것과 같은 작업을 수행합니다.
호스트 이름이지만 이 옵션을 사용하여 호스트 이름을 몇 개 지정하면 속도가 빨라질 수 있습니다.
에서 시작하다.

--대기 시간 제어 없음
대역폭 벤치마크를 개선하기 위해 대기 시간을 희생하십시오. ssh는 정말 큰 소켓을 사용합니다
대용량 파일 전송을 시작하면 연결에 과부하가 걸릴 수 있는 버퍼,
따라서 동일한 터널 내의 다른 모든 세션이 느리게 진행됩니다. 보통,
셔틀 만 허용하는 "충만 검사"를 사용하여 이 문제를 피하려고 합니다.
한 번에 버퍼링할 미해결 데이터의 특정 양. 그러나 고대역폭에서
링크를 사용하면 대역폭이 많이 활용되지 않을 수 있습니다. 그것은 또한 만든다
셔틀 대역폭 벤치마크에서 느린 것처럼 보입니다(벤치마크는 핑 대기 시간을 거의 테스트하지 않으며,
무엇인가 셔틀 제어하려고 합니다). 이 옵션은 대기 시간을 비활성화합니다.
대역폭 사용을 최대화하는 제어 기능. 자신의 책임하에 사용하십시오.

-NS, --악마
원격 서버에 연결한 후 자동으로 백그라운드로 분기합니다.
암시 --syslog.

--syslog
연결 후 모든 로그 메시지를 syslog(3) stderr 대신 서비스.
이것은 다음을 사용하는 경우 암시적입니다. --악마.

--pidfile=pid파일명
사용하는 경우 --악마, 저장 셔틀의 PID PID 파일 이름. 기본값은
셔틀.피드 현재 디렉토리에서.

--비활성화-ipv6
tproxy 방법을 사용하는 경우 IPv6 지원이 비활성화됩니다.

--방화벽
(내부 전용) 방화벽 관리자를 실행합니다. 이것은 유일한 부분이다. 셔틀
루트로 실행해야 합니다. 시작하면 셔틀 루트가 아닌 사용자로서
자동으로 실행 sudo는 or su 방화벽 관리자를 시작하기 위해
셔틀 여전히 일반 사용자로 실행됩니다.

--호스트워치
(내부 전용) hostwatch 데몬을 실행합니다. 이 프로세스는 서버 측에서 실행됩니다.
에 대한 호스트 이름을 수집합니다. --자동 호스트 옵션. 이 옵션을 단독으로 사용
디버그 및 테스트를 훨씬 쉽게 만듭니다. --자동 호스트 기능.

사용 예

ssh를 사용하지 않고 모든 로컬 연결을 프록시하여 로컬에서 테스트:

$ 셔틀 -v 0/0

셔틀 프록시를 시작합니다.
('0.0.0.0', 12300)을 듣고 있습니다.
[로컬 sudo] 비밀번호:
방화벽 관리자가 준비되었습니다.
c : 서버에 연결 중...
s: 사용 가능한 경로:
초: 192.168.42.0/24
c : 연결되었습니다.
방화벽 관리자: 트랜스프록시를 시작합니다.
c : 수락: 192.168.42.106:50035 -> 192.168.42.121:139.
c : 수락: 192.168.42.121:47523 -> 77.141.99.22:443.
...기타...
^C
방화벽 관리자: 변경 사항을 실행 취소합니다.
키보드 인터럽트
c : 키보드 인터럽트: 종료.
c : SW#8:192.168.42.121:47523: 삭제
c : SW#6:192.168.42.106:50035: 삭제

자동 호스트 이름 및 서브넷 추측으로 원격 서버에 대한 연결 테스트:

$ sshuttle -vNHr example.org

셔틀 프록시를 시작합니다.
('0.0.0.0', 12300)을 듣고 있습니다.
방화벽 관리자가 준비되었습니다.
c : 서버에 연결 중...
s: 사용 가능한 경로:
초: 77.141.99.0/24
c : 연결되었습니다.
c : 시드_호스트: []
방화벽 관리자: 트랜스프록시를 시작합니다.
hostwatch: 발견: testbox1: 1.2.3.4
호스트 워치: 발견: mytest2: 5.6.7.8
hostwatch: 발견: domaincontroller: 99.1.2.3
c : 수락: 192.168.42.121:60554 -> 77.141.99.22:22.
^C
방화벽 관리자: 변경 사항을 실행 취소합니다.
c : 키보드 인터럽트: 종료.
c : SW#6:192.168.42.121:60554: 삭제

토론

시작될 때, 셔틀 에 의해 지정된 서버에 대한 ssh 세션을 생성합니다. -r 옵션을 선택합니다.
If -r 생략하면 클라이언트와 서버를 모두 로컬로 시작합니다.
테스트에 유용합니다.

원격 서버에 접속한 후, 셔틀 (파이썬) 소스 코드를
원격 종료하고 거기에서 실행합니다. 따라서 설치할 필요가 없습니다. 셔틀 리모컨에서
서버, 그리고 결코 셔틀 클라이언트와 서버 간의 버전 충돌.

대부분의 VPN과 달리 셔틀 패킷이 아닌 세션을 전달합니다. 즉, 커널을 사용합니다.
투명 프록시(iptables에 리디렉션 Linux의 규칙) 나가는 TCP 세션을 캡처하기 위해
그런 다음 다른 쪽의 원래 대상으로 완전히 별도의 TCP 세션을 만듭니다.
터널의 끝.

패킷 수준 전달(예: Linux에서 tun/tap 장치 사용)은 처음에는 우아해 보이지만,
그러나 여러 문제, 특히 'tcp over tcp' 문제가 발생합니다. TCP 프로토콜
기본적으로 혼잡을 구현하기 위해 삭제되는 패킷에 의존합니다.
제어 알고리즘; tcp 기반 터널(예: ssh)을 통해 tcp 패킷을 전달하면
내부 tcp 패킷은 절대 삭제되지 않으므로 내부 tcp 스트림의 혼잡 제어
완전히 망가지고 성능이 끔찍할 것입니다. 따라서 패킷 기반 VPN
(IPsec 및 openvpn과 같은) ssh 또는 ssl과 같은 tcp 기반 암호화된 스트림을 사용할 수 없습니다.
매우 복잡하고 오류가 있는 자체 암호화를 처음부터 구현해야 합니다.
경향이있다.

셔틀의 단순성은 기존 ssh를 안전하게 사용할 수 있다는 사실에서 비롯됩니다.
성능 저하 없이 암호화된 터널. 그것은
클라이언트 측 커널은 들어오는 tcp 스트림을 관리하고 서버 측 커널은
나가는 TCP 스트림; 둘 사이에 혼잡 제어를 공유할 필요가 없습니다.
스트림을 분리하므로 tcp 기반 터널이 좋습니다.

onworks.net 서비스를 사용하여 sshuttle 온라인 사용