sshuttle - クラウドでオンライン

プログラム：

NAME

sshuttle - sshuttle ドキュメント

SYNOPSIS

シャトル [オプション] [-r [ユーザー名@]sshサーバー[:ポート]]サブネット ...>

DESCRIPTION

シャトル マシンから任意のリモート サーバーへの VPN 接続を作成できます。
サーバーに Python 2.3 以降が搭載されている限り、ssh 経由で接続できます。

作業するには、ローカル マシン上で root アクセス権が必要ですが、通常のアカウントを持つことができます。
サーバー上で

実行するのは有効です シャトル 単一のクライアント マシン上で同時に複数回、
毎回異なるサーバーに接続するため、同時に複数の VPN に接続できます。

ルーター上で実行すると、 シャトル サブネット全体のトラフィックを VPN に転送できます。

OPTIONS

サブネット
VPN 経由でルーティングするサブネットのリスト (次の形式) abcd[/width]。 有効
例は、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 経由でルーティングします」)。

-l、 --listen=[ip:]ポート
この IP アドレスとポート番号を透過プロキシ ポートとして使用します。 デフォルトでは
シャトル 利用可能なポートを自動的に見つけて、IP 127.0.0.1 をリッスンします。
(localhost) なのでオーバーライドする必要はなく、接続はプロキシされるだけです
外部マシンからではなく、ローカルマシンから。 受け入れたい場合は
ネットワーク上の他のマシンからの接続 (つまり、 シャトル ルーター上）
カーネルで IP 転送を有効にしてから、次を使用してみてください。 - 聞く 0.0.0.0:0.

tproxy 方式の場合、これは IPv6 アドレスになります。 次の場合にこのオプションを XNUMX 回使用します
IPv4 アドレスと IPv6 アドレスの両方を提供するために必要です。

-NS、 -- 自動ホスト
リモートホスト名をスキャンし、ローカルホスト名を更新します /etc/hosts 一致するファイル
VPN が開いている限り、エントリが保持されます。 これはシステムを変更するよりも優れています
DNS（/etc/resolv.conf) の設定には、いくつかの理由があります。 まず、ホスト名が追加されます
ドメイン名が付加されていないため、 ssh そのサーバー 心配する必要はありません
ローカル ドメインがリモート ドメインと一致します。 第二に、もしあなたが シャトル 複数に分けて
VPN を一度に複数の DNS サーバーを同時に使用することは不可能ですが、
シャトル 正しくマージします /etc/hosts 実行中のすべてのコピー間のエントリ。 第三に、もし
VPN 経由で少数のサブネットのみをルーティングしている場合は、おそらくそのままにしておくほうがよいでしょう。
それ以外はすべてローカル DNS サーバーを使用します。

-NS、 --auto-nets
コマンドラインで指定したサブネットに加えて、どのサブネットを使用するかをサーバーに問い合わせます。
ルーティングする必要があると考えられるサブネットを自動的にルーティングします。 提案
サーバーのルーティング テーブルから自動的に取得されます。

--DNS ローカル DNS リクエストをキャプチャし、リモート DNS サーバーに転送します。

--Python
リモート Python インタープリターの名前/パスを指定します。 デフォルトはただ
パイソンこれは、リモート システムのデフォルトの Python インタープリタを使用することを意味します。
道。

-NS、 --remote=[ユーザー名@]sshserver[:ポート]
接続に使用するリモートのホスト名とオプションのユーザー名および SSH ポート番号
リモートサーバーに送信します。 たとえば、example.com、 testuser@example.com,
testuser@example.com:2222、または example.com:2244。

-NS、 --exclude=サブネット
このサブネットを転送から明示的に除外します。 このオプションの形式は次のとおりです。
と同じ オプション。 複数のサブネットを除外するには、 -x
オプションを複数回使用します。 次のようなことが言えます 0/0 -x 1.2.3.0/24 前に
たとえば、VPN 上のローカル サブネットを除くすべて。

-NS、 --exclude-from=ファイル
ファイルで指定されたサブネットを XNUMX 行に XNUMX つずつ除外します。 あるときに便利です
除外するサブネットがたくさんあります。

-v、 -詳細
セッションに関する詳細情報を出力します。 このオプションは複数回使用できます
冗長性を高めるために。 デフォルトでは、 シャトル エラーメッセージのみを出力します。

-e、 --ssh-cmd
リモートサーバーへの接続に使用するコマンド。 デフォルトはただ ssh。 使用
これは、SSH クライアントが標準以外の場所にある場合、または追加の場所を提供したい場合に使用します。
ssh コマンドのオプション。たとえば、 -e しっ -v'.

--シードホスト
初期化に使用するホスト名のカンマ区切りのリスト。 -- 自動ホスト スキャン
アルゴリズム。 -- 自動ホスト ローカル SMB サーバーにポーリングしてローカルのリストを取得するなどの処理を行います。
ただし、このオプションを使用してホスト名にいくつかの名前を付けると、処理が高速化されます。
から始まる。

--no-latency-control
遅延を犠牲にして帯域幅のベンチマークを向上させます。 ssh は非常に大きなソケットを使用します
バッファ。大きなファイルの転送を開始すると接続に過負荷がかかる可能性があります。
したがって、同じトンネル内の他のすべてのセッションの進行が遅くなります。 通常は、
シャトル は、
一度に一定量の未処理のデータをバッファリングします。 ただし、高帯域幅では
リンクを使用すると、帯域幅の多くが十分に活用されないままになる可能性があります。 また、
シャトル 帯域幅ベンチマークでは遅いように見えます (ベンチマークでは ping 遅延をほとんどテストしません。
これは何ですか シャトル コントロールしようとしている）。 このオプションはレイテンシーを無効にします
制御機能により、帯域幅の使用量を最大化します。 自己責任。

-NS、 - デーモン
リモートサーバーに接続した後、自動的にバックグラウンドにフォークします。
示す --syslog.

--syslog
接続後、すべてのログ メッセージを syslog(3) 標準エラー出力の代わりにサービスを使用します。
を使用する場合、これは暗黙的です - デーモン.

--pidfile=pidファイル名
使用している場合 - デーモン、 保存する シャトルのpid to pidファイル名。 デフォルトは
sshuttle.pid 現在のディレクトリにあります。

--disable-ipv6
tproxy 方式を使用する場合、IPv6 サポートが無効になります。

--ファイアウォール
(内部使用のみ) ファイアウォール マネージャーを実行します。 これはその唯一の部分です シャトル
root として実行する必要があります。 始めたら シャトル 非 root ユーザーとしては、
自動的に実行される sudo or su ファイアウォールマネージャーを起動しますが、コアは
シャトル 引き続き通常のユーザーとして実行されます。

-- ホストウォッチ
(内部使用のみ) hostwatch デーモンを実行します。 このプロセスはサーバー側で実行されます
のホスト名を収集します。 -- 自動ホスト オプション。 このオプションを単独で使用する
デバッグとテストがはるかに簡単になります -- 自動ホスト 特徴。

例

SSH を使用せずに、すべてのローカル接続をプロキシしてローカルでテストします。

$ シャトル -v 0/0

シャトルプロキシを開始しています。
('0.0.0.0', 12300) をリッスンしています。
[ローカル sudo] パスワード:
ファイアウォールマネージャーの準備ができました。
c : サーバーに接続中...
s: 利用可能なルート:
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: 利用可能なルート:
s：77.141.99.0 / 24
c : 接続されています。
c : シードホスト: []
ファイアウォール マネージャー: トランスプロキシを開始しています。
ホストウォッチ: 見つかりました: testbox1: 1.2.3.4
ホストウォッチ: 見つかりました: mytest2: 5.6.7.8
ホストウォッチ: 見つかりました: ドメインコントローラー: 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 を省略すると、クライアントとサーバーの両方がローカルで起動されます。
テストに役立ちます。

リモートサーバーに接続したら、 シャトル (Python) ソース コードを
リモートエンドに接続し、そこで実行します。 したがって、インストールする必要はありません シャトル リモートで
サーバー、そして決して存在しません シャトル クライアントとサーバーの間でバージョンが競合します。

ほとんどの 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 ストリーム。 XNUMX つの間で輻輳制御を共有する必要はありません。
別々のストリームなので、TCP ベースのトンネルで問題ありません。

onworks.net サービスを使用してオンラインで sshuttle を使用する