sshuttle - ออนไลน์ในคลาวด์

โครงการ:

ชื่อ

sshuttle - เอกสารรถรับส่ง

เรื่องย่อ

รถรับส่ง [ตัวเลือก] [-r [ชื่อผู้ใช้@]sshเซิร์ฟเวอร์[:พอร์ต]]ซับเน็ต ...>

DESCRIPTION

รถรับส่ง ให้คุณสร้างการเชื่อมต่อ VPN จากเครื่องของคุณไปยังเซิร์ฟเวอร์ระยะไกลที่
คุณสามารถเชื่อมต่อผ่าน ssh ได้ตราบใดที่เซิร์ฟเวอร์นั้นมี python 2.3 หรือสูงกว่า

ในการทำงาน คุณต้องมีการเข้าถึงรูทบนเครื่องท้องถิ่น แต่คุณสามารถมีบัญชีปกติได้
บนเซิร์ฟเวอร์

มันถูกต้องที่จะเรียกใช้ รถรับส่ง พร้อมกันบนเครื่องไคลเอนต์เครื่องเดียวมากกว่าหนึ่งครั้ง
เชื่อมต่อกับเซิร์ฟเวอร์อื่นทุกครั้ง ดังนั้นคุณจึงสามารถใช้ VPN ได้มากกว่าหนึ่งแห่งในคราวเดียว

หากทำงานบนเราเตอร์ รถรับส่ง สามารถส่งต่อทราฟฟิกสำหรับซับเน็ตทั้งหมดของคุณไปยัง VPN

OPTIONS

ซับเน็ต
รายการซับเน็ตที่จะกำหนดเส้นทางผ่าน 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')

-l --listen=[ip:]พอร์ต
ใช้ที่อยู่ IP และหมายเลขพอร์ตนี้เป็นพอร์ตพร็อกซีแบบโปร่งใส โดยค่าเริ่มต้น
รถรับส่ง ค้นหาพอร์ตที่มีอยู่โดยอัตโนมัติและฟังบน IP 127.0.0.1
(localhost) ดังนั้นคุณไม่จำเป็นต้องแทนที่มัน และการเชื่อมต่อเป็นเพียงพร็อกซี่
จากเครื่องในเครื่อง ไม่ใช่เครื่องนอก หากคุณต้องการที่จะยอมรับ
การเชื่อมต่อจากเครื่องอื่นในเครือข่ายของคุณ (เช่น เพื่อเรียกใช้ รถรับส่ง บนเราเตอร์)
ลองเปิดใช้งานการส่งต่อ IP ในเคอร์เนลของคุณ จากนั้นใช้ --ฟัง 0.0.0.0:0.

สำหรับวิธี tproxy นี่อาจเป็นที่อยู่ IPv6 ใช้ตัวเลือกนี้สองครั้ง if
จำเป็น เพื่อระบุทั้งที่อยู่ IPv4 และ IPv6

-ชม, --auto-โฮสต์
สแกนหาชื่อโฮสต์ระยะไกลและอัปเดตท้องถิ่น / etc / hosts ไฟล์ที่มีการจับคู่
รายการตราบเท่าที่ VPN เปิดอยู่ มันดีกว่าการเปลี่ยนระบบของคุณ
ดีเอสเอ็น (/ etc / resolv.conf) การตั้งค่า ด้วยเหตุผลหลายประการ ขั้นแรก เพิ่มชื่อโฮสต์
โดยไม่ต้องแนบชื่อโดเมน คุณจึงสามารถ SSH เซิร์ฟเวอร์นั้น โดยไม่ต้องกังวลว่า
โดเมนท้องถิ่นตรงกับโดเมนระยะไกล ประการที่สอง ถ้าคุณ รถรับส่ง มากกว่าหนึ่ง
VPN ในแต่ละครั้ง เป็นไปไม่ได้ที่จะใช้เซิร์ฟเวอร์ DNS มากกว่าหนึ่งเครื่องพร้อมกัน แต่
รถรับส่ง ผสานอย่างถูกต้อง / etc / hosts รายการระหว่างสำเนาที่ทำงานอยู่ทั้งหมด ประการที่สาม if
คุณกำลังกำหนดเส้นทางเครือข่ายย่อยเพียงไม่กี่เครือข่ายผ่าน VPN คุณอาจต้องการเก็บไว้
ใช้เซิร์ฟเวอร์ DNS ในพื้นที่ของคุณสำหรับอย่างอื่น

-NS, --auto-มุ้ง
นอกเหนือจากซับเน็ตที่ให้มาในบรรทัดคำสั่ง ให้ถามเซิร์ฟเวอร์ซึ่ง
เครือข่ายย่อยที่คิดว่าเราควรกำหนดเส้นทางและกำหนดเส้นทางโดยอัตโนมัติ คำแนะนำ
จะถูกนำมาโดยอัตโนมัติจากตารางเส้นทางของเซิร์ฟเวอร์

--dns ดักจับคำขอ DNS ในพื้นที่และส่งต่อไปยังเซิร์ฟเวอร์ DNS ระยะไกล

--หลาม
ระบุชื่อ/เส้นทางของล่ามหลามระยะไกล ค่าเริ่มต้นคือเพียง
หลามซึ่งหมายถึงการใช้ตัวแปล 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-จาก = ไฟล์
ยกเว้นซับเน็ตที่ระบุในไฟล์ หนึ่งซับเน็ตต่อบรรทัด มีประโยชน์เมื่อคุณมี
ซับเน็ตจำนวนมากที่จะยกเว้น

-ใน, --รายละเอียด
พิมพ์ข้อมูลเพิ่มเติมเกี่ยวกับเซสชั่น ตัวเลือกนี้สามารถใช้ได้มากกว่าหนึ่งครั้ง
เพื่อเพิ่มอรรถรส โดยค่าเริ่มต้น, รถรับส่ง พิมพ์เฉพาะข้อความแสดงข้อผิดพลาด

-e, --ssh-cmd
คำสั่งที่ใช้เชื่อมต่อกับเซิร์ฟเวอร์ระยะไกล ค่าเริ่มต้นคือเพียง SSH. ใช้
นี่ถ้าไคลเอนต์ ssh ของคุณอยู่ในตำแหน่งที่ไม่ได้มาตรฐานหรือคุณต้องการให้พิเศษ
ตัวเลือกสำหรับคำสั่ง ssh เช่น -e 'ssh -v'.

--เมล็ดพันธุ์-เจ้าภาพ
รายการชื่อโฮสต์ที่คั่นด้วยเครื่องหมายจุลภาคเพื่อใช้เริ่มต้น --auto-โฮสต์ การสแกน
ขั้นตอนวิธี --auto-โฮสต์ ทำสิ่งต่างๆ เช่น สำรวจเซิร์ฟเวอร์ SMB ในพื้นที่สำหรับรายการท้องถิ่น
ชื่อโฮสต์ แต่สามารถเพิ่มความเร็วได้หากคุณใช้ตัวเลือกนี้เพื่อตั้งชื่อให้
เริ่มต้นจาก.

--no-latency-ควบคุม
สละเวลาแฝงเพื่อปรับปรุงเกณฑ์มาตรฐานแบนด์วิดท์ ssh ใช้ซ็อกเก็ตขนาดใหญ่จริงๆ
บัฟเฟอร์ซึ่งสามารถโอเวอร์โหลดการเชื่อมต่อได้หากคุณเริ่มทำการถ่ายโอนไฟล์ขนาดใหญ่
จึงทำให้เซสชันอื่นๆ ทั้งหมดของคุณภายในอุโมงค์เดียวกันดำเนินไปอย่างช้าๆ โดยทั่วไป,
รถรับส่ง พยายามหลีกเลี่ยงปัญหานี้โดยใช้ "การตรวจสอบความสมบูรณ์" ที่อนุญาตเฉพาะ a
ข้อมูลคงค้างจำนวนหนึ่งที่จะบัฟเฟอร์ในแต่ละครั้ง แต่บนแบนด์วิดธ์สูง
ลิงก์ อาจทำให้แบนด์วิดท์ของคุณใช้งานไม่ได้มาก ยังทำให้
รถรับส่ง ดูเหมือนช้าในการวัดประสิทธิภาพแบนด์วิดท์ (เกณฑ์มาตรฐานไม่ค่อยทดสอบเวลาแฝงของ ping
มันคืออะไร รถรับส่ง กำลังพยายามควบคุม) ตัวเลือกนี้ปิดใช้งานเวลาแฝง
คุณสมบัติการควบคุม เพิ่มการใช้แบนด์วิธให้สูงสุด ใช้ความเสี่ยงของคุณเอง

-NS, --ภูต
แยกเป็นพื้นหลังโดยอัตโนมัติหลังจากเชื่อมต่อกับเซิร์ฟเวอร์ระยะไกล
หมายถึง --syslog.

--syslog
หลังจากเชื่อมต่อแล้ว ให้ส่งข้อความบันทึกทั้งหมดไปที่ syslog(3) บริการแทน stderr
นี่เป็นโดยปริยายหากคุณใช้ --ภูต.

--pidfile=pidfilename
เมื่อใช้ --ภูต, บันทึก รถรับส่งของ pid to pidชื่อไฟล์. ค่าเริ่มต้นคือ
sshuttle.pid ในไดเร็กทอรีปัจจุบัน

--ปิดการใช้งาน-ipv6
หากใช้วิธี tproxy จะเป็นการปิดการรองรับ IPv6

--ไฟร์วอลล์
(ใช้ภายในเท่านั้น) เรียกใช้ตัวจัดการไฟร์วอลล์ นี่เป็นเพียงส่วนเดียวของ รถรับส่ง
ที่ต้องทำงานเป็นรูท ถ้าคุณเริ่ม รถรับส่ง ในฐานะผู้ใช้ที่ไม่ใช่รูท มันจะ
ทำงานอัตโนมัติ sudo or su เพื่อเริ่มต้นตัวจัดการไฟร์วอลล์ แต่หลักของ
รถรับส่ง ยังคงทำงานเหมือนผู้ใช้ทั่วไป

--โฮสต์วอทช์
(ใช้ภายในเท่านั้น) เรียกใช้ hostwatch daemon กระบวนการนี้ทำงานบนฝั่งเซิร์ฟเวอร์
และรวบรวมชื่อโฮสต์สำหรับ --auto-โฮสต์ ตัวเลือก. ใช้ตัวเลือกนี้ด้วยตัวเอง
ทำให้ง่ายต่อการดีบักและทดสอบ --auto-โฮสต์ ลักษณะ

ตัวอย่าง

ทดสอบในเครื่องโดยพร็อกซีการเชื่อมต่อในเครื่องทั้งหมดโดยไม่ต้องใช้ ssh:

$ รถรับส่ง -v 0/0

กำลังเริ่มต้นพร็อกซีรถรับส่ง
กำลังฟัง ('0.0.0.0', 12300)
[ท้องถิ่น sudo] รหัสผ่าน:
ตัวจัดการไฟร์วอลล์พร้อม
c : กำลังเชื่อมต่อกับเซิร์ฟเวอร์...
s: เส้นทางที่ใช้ได้:
วินาที: 192.168.42.0/24
ค : เชื่อมต่อ
ตัวจัดการไฟร์วอลล์: เริ่มต้น transproxy
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
ค : เชื่อมต่อ
ค : seed_hosts: []
ตัวจัดการไฟร์วอลล์: เริ่มต้น transproxy
hostwatch: พบ: testbox1: 1.2.3.4
hostwatch: พบ: 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 จะถูกละเว้น มันจะเริ่มต้นทั้งไคลเอนต์และเซิร์ฟเวอร์ในเครื่อง ซึ่งบางครั้ง
มีประโยชน์สำหรับการทดสอบ

หลังจากเชื่อมต่อกับเซิร์ฟเวอร์ระยะไกลแล้ว รถรับส่ง อัปโหลดซอร์สโค้ด (python) ไปยัง
สิ้นสุดระยะไกลและดำเนินการที่นั่น ดังนั้นคุณไม่จำเป็นต้องติดตั้ง รถรับส่ง บนรีโมท
เซิร์ฟเวอร์และไม่เคยมี รถรับส่ง เวอร์ชันที่ขัดแย้งกันระหว่างไคลเอนต์และเซิร์ฟเวอร์

ไม่เหมือนกับ VPN ส่วนใหญ่ รถรับส่ง ส่งต่อเซสชัน ไม่ใช่แพ็กเก็ต นั่นคือมันใช้เคอร์เนล
พร็อกซี่โปร่งใส (iptables เปลี่ยนเส้นทาง กฎบน Linux) เพื่อดักจับเซสชัน TCP ขาออก
จากนั้นสร้างเซสชัน TCP ที่แยกจากกันทั้งหมดไปยังปลายทางเดิมที่อื่น
ปลายอุโมงค์.

การส่งต่อระดับแพ็กเก็ต (เช่น การใช้อุปกรณ์ tun/tap บน Linux) ดูสวยงามในตอนแรก
แต่มันส่งผลให้เกิดปัญหาหลายประการ โดยเฉพาะปัญหา 'tcp over tcp' โปรโตคอล TCP
ขึ้นอยู่กับแพ็กเก็ตที่ถูกทิ้งโดยพื้นฐานเพื่อให้เกิดความแออัดของมัน
agorithm ควบคุม; หากคุณส่งแพ็กเก็ต TCP ผ่านช่องสัญญาณที่ใช้ TCP (เช่น ssh) the
แพ็กเก็ต tcp ภายในจะไม่ถูกทิ้ง ดังนั้นการควบคุมความแออัดของสตรีม tcp ภายใน
จะพังยับเยินและการแสดงจะแย่มาก ดังนั้น VPN แบบแพ็กเก็ต
(เช่น IPsec และ openvpn) ไม่สามารถใช้สตรีมที่เข้ารหัสแบบ tcp เช่น ssh หรือ ssl และ
ต้องใช้การเข้ารหัสของตัวเองตั้งแต่ต้น ซึ่งซับซ้อนและผิดพลาดมาก
มีแนวโน้ม

รถรับส่งความเรียบง่ายของมาจากความจริงที่ว่ามันสามารถใช้ ssh . ที่มีอยู่ได้อย่างปลอดภัย
อุโมงค์ที่เข้ารหัสโดยไม่ทำให้เสียประสิทธิภาพการทำงาน มันทำสิ่งนี้โดยปล่อยให้
เคอร์เนลฝั่งไคลเอ็นต์จัดการกระแสข้อมูล TCP ขาเข้า และเคอร์เนลฝั่งเซิร์ฟเวอร์จัดการ
กระแสข้อมูล TCP ขาออก; ไม่จำเป็นต้องมีการควบคุมความแออัดร่วมกันระหว่างคนทั้งสอง
แยกสตรีม ดังนั้นอุโมงค์ที่ใช้ TCP ก็ใช้ได้

ใช้ sshuttle ออนไลน์โดยใช้บริการ onworks.net