tunnel
1.0.0
ตัวส่งต่อพอร์ต TCP/UDP ที่ปลอดภัย มัลติเพล็กซ์ โดยใช้ piping-server โดย @nwtgck เป็นรีเลย์ ออกแบบมาเพื่อการเชื่อมต่อ p2p ระหว่างเพียร์ที่อยู่เบื้องหลัง NAT/ไฟร์วอลล์ (หลายตัว) เป็นหลัก
สำหรับกรณีพิเศษของ IPFS โปรดดู #examples ด้านล่าง
ID: ทุกโหนดจะได้รับ ID ที่ไม่ซ้ำกัน (base64) -
tunnel -iID ถูกผูกไว้กับฮาร์ดแวร์ (ที่อยู่ MAC) และตัวแปรสภาพแวดล้อม USER, HOME และ HOSTNAME แบ่งปันกับเพื่อนของคุณทันทีและตลอดไป หมายเหตุ: ผู้ใช้สองคนบนเครื่องเดียวกันจะได้รับ node-ID แยกกัน เนื่องจากตัวแปร USER และ HOME แตกต่างกัน
โหมดเซิร์ฟเวอร์: เปิดเผยพอร์ตในเครื่องของคุณให้กับเพื่อนที่คุณแชร์สตริงลับด้วย -
tunnel [options] [-u] [-k < shared-secret > ] < local-port >โหมดไคลเอนต์: ส่งต่อพอร์ตในเครื่องของคุณไปยังพอร์ตในเครื่องที่เปิดเผยของเพียร์ -
tunnel [options] [-u] [-k < shared-secret > ] [-b < local-port > ] [-I < IP > ] < peer-ID:peer-port > หากไม่มีการระบุพอร์ตโลคัลโดยใช้อ็อพชัน -b ช่อง tunnel จะใช้พอร์ตที่ไม่ได้ใช้แบบสุ่ม พอร์ตที่ใช้จะถูกรายงานที่ stdout เสมอ
ตัวเลือก -I มีประโยชน์เมื่อไคลเอ็นต์ทำงานบนแล็ปท็อปซึ่งบางครั้งจะเชื่อมต่อกับ LAN ที่เซิร์ฟเวอร์เปิดอยู่ เมื่อเซิร์ฟเวอร์สามารถพบได้บน LAN ด้วย IP ส่วนตัว = <IP> tunnel จะเชื่อมต่อผ่าน LAN
ไคลเอนต์และเซิร์ฟเวอร์ต้องใช้ความลับเดียวกันเพื่อให้สามารถเชื่อมต่อถึงกันได้ สตริงลับยังสามารถส่งผ่านโดยใช้ตัวแปรสภาพแวดล้อม TUNNEL_KEY ความลับที่ส่งผ่านโดย -k มีความสำคัญกว่า
-u แฟล็กหมายถึงการใช้ UDP แทน TCP เริ่มต้น หากใช้จะต้องใช้โดยทั้งเพื่อน
บันทึกทั้งหมดอยู่ที่ stderr ตามค่าเริ่มต้น อย่างไรก็ตาม ด้วยตัวเลือก -l <logfile> เราสามารถเปิด tunnel ในพื้นหลัง ( โหมด daemon ) โดยมีบันทึกที่ดัมพ์ที่ <logfile> รหัสกระบวนการ daemon จะแสดงให้ผู้ใช้เห็นในระหว่างการเปิดตัว เพื่อให้เขาสามารถฆ่า daemon ได้ทุกเมื่อ
tunnel -K < procID >ตัวเลือก:
สำหรับรายการตัวเลือกทั้งหมด โปรดดูที่ : tunnel -h
ดาวน์โหลดด้วย:
curl -LO https://raw.githubusercontent.com/SomajitDey/tunnel/main/tunnelทำให้ปฏิบัติการได้:
chmod +rx ./tunnelจากนั้นติดตั้งทั้งระบบด้วย:
./tunnel -c install หากคุณไม่มีสิทธิ์ sudo คุณสามารถติดตั้งในเครื่องแทนได้:
./tunnel -c install -lหากต้องการอัปเดตเมื่อใดก็ได้หลังการติดตั้ง:
tunnel -c update โปรแกรมนี้เป็นเพียงสคริปต์ bash ที่เรียกใช้งานได้ขึ้นอยู่กับเครื่องมือ GNU มาตรฐานรวมถึง socat , openssl , curl , mktemp , cut , awk , sed , flock , pkill , dd , xxd , base64 ฯลฯ ที่พร้อมใช้งานบน Linux distros มาตรฐาน
หากระบบของคุณขาดเครื่องมือเหล่านี้ และคุณไม่มีสิทธิ์ sudo ที่จำเป็นในการติดตั้งจากที่เก็บแพ็กเกจดั้งเดิม (เช่น sudo apt-get install <package> ) ให้ลองดาวน์โหลดไบนารีแบบพกพาและติดตั้งในเครื่องที่ ${HOME}/.bin
เอสเอสเอช :
Peer A เปิดเผยพอร์ต SSH ในเครื่อง -
tunnel -k " ${secret} " 22เพียร์ B เชื่อมต่อ -
tunnel -b 67868 -k " ${secret} " -l /dev/null " ${peerA_ID} :22 " # Daemon due to -l
ssh -l " ${login_name} " -p 67868 localhost ไอพีเอฟเอส :
ให้เพียร์ A มี IPFS-peer-ID: 12orQmAlphanumeric IPFS daemon ของเธอฟังที่พอร์ต TCP เริ่มต้น 4001 เธอเปิดเผยด้วย -
tunnel -k " ${swarm_key} " ipfs swarm_key เป็นเพียงสตริงเพียร์ลับใดๆ ที่ A อาจใช้เพื่อควบคุมว่าใครสามารถเชื่อมต่อกับเธอโดยใช้ tunnel
ขณะนี้ Peer B เชื่อมต่อกับ peer A สำหรับการแชร์ไฟล์หรือ pubsub หรือ p2p -
tunnel -k " ${swarm_key} " 12orQmAlphanumericคำสั่งสุดท้ายนี้จะเชื่อมต่อกับเพียร์ A ผ่านทางรีเลย์เซิร์ฟเวอร์ท่อ และทำการเชื่อมต่อเป็นกลุ่มทุกๆ สองสามวินาทีในเบื้องหลังเพื่อรักษาการเชื่อมต่อให้คงอยู่
tunnel สตาร์ท IPFS daemon ในเบื้องหลัง หากยังไม่ได้แอ็คทีฟ
เส้นทางไปยัง repo IPFS อาจถูกส่งผ่านด้วยตัวเลือก -r มิฉะนั้น ตัวแปรสภาพแวดล้อม IPFS_PATH หรือเส้นทางเริ่มต้น ~/.ipfs จะถูกใช้ตามปกติ ตัวอย่าง: tunnel -r ~/.ipfs -i ให้ IPFS peer ID
เชลล์ระยะไกล :
สมมติว่าคุณจะต้องเรียกใช้คำสั่งที่กล่อง Linux ที่ทำงานของคุณจากเครื่องที่บ้านเป็นประจำ และคุณไม่ต้องการ / ไม่สามารถใช้ SSH บน tunnel ได้ด้วยเหตุผลบางประการ
ที่คอมพิวเตอร์ในที่ทำงาน ให้เปิดเผยพอร์ต TCP ในเครื่องแบบสุ่ม เช่น 49090 และเชื่อมต่อเชลล์เข้ากับพอร์ตนั้น:
tunnel -l " /tmp/tunnel.log " -k " your secret " 49090 # Note the base64 node id emitted
socat TCP-LISTEN:49090,reuseaddr,fork SYSTEM: ' bash 2>&1 'กลับบ้านของคุณ:
tunnel -l " /dev/null " -b 5000 -k " your secret " " node_id_of_workplace:49090 "
rlwrap nc localhost 5000การใช้ rlwrap ไม่ใช่สิ่งจำเป็น แต่จะทำให้ประสบการณ์นั้นหอมหวานยิ่งขึ้นอย่างแน่นอน เนื่องจากใช้ GNU Readline และจดจำประวัติอินพุต (สามารถเข้าถึงได้ด้วยปุ่มลูกศรขึ้น/ลงที่คล้ายกับเซสชันทุบตีในเครื่องของคุณ)
เรดดิส :
ต้องการเชื่อมต่อกับอินสแตนซ์ Redis ระยะไกลที่โฮสต์โดยเพียร์หรือตัวคุณเองหรือไม่ ที่โฮสต์ระยะไกล ให้เปิดเผยพอร์ต TCP ที่ redis-server ทำงานอยู่ (ค่าเริ่มต้น: 6379) พร้อมด้วย tunnel
ที่เครื่องท้องถิ่นของคุณ ให้ใช้ tunnel เพื่อส่งต่อพอร์ต TCP ไปยังพอร์ตระยะไกล ชี้ redis-cli ของคุณไปที่พอร์ตโลคัลที่ส่งต่อ
ด้านล่างนี้เป็นกรณีการใช้งานแบบสุ่มที่ฉันนึกถึงสำหรับ tunnel พูดอย่างกว้างๆ สิ่งใดก็ตามที่เกี่ยวข้องกับการแวะผ่าน NAT/ไฟร์วอลล์ (เช่น WebRTC ที่ไม่มี TURN) หรือการเข้าร่วม LAN ระยะไกล ควรพบว่า tunnel มีประโยชน์ แนวคิดบางส่วนต่อไปนี้ค่อนข้างคลุมเครือ ไม่ได้รับการทดสอบเลย และอาจใช้ไม่ได้ผล แต่อย่างไรก็ตาม ได้มีการบันทึกไว้ที่นี่ อย่างน้อยก็ในขณะนี้ เพียงเพื่อประโยชน์ในการสร้างแรงบันดาลใจ หากคุณพบว่าสิ่งเหล่านี้มีประโยชน์หรือไม่มีประโยชน์ หรือคุณพบแอปพลิเคชันใหม่สำหรับ tunnel โปรดโพสต์ที่การสนทนา กรณีเหล่านั้นที่ฉันทดสอบแล้วมีป้ายกำกับว่า "ใช้งานได้"
tunneltunnel ที่ Heroku (ฟรี) และส่งต่อพอร์ตที่เก็บไว้ในตัวแปรสภาพแวดล้อม PORT ไปยังพอร์ตในเครื่องของคุณที่คุณต้องการเปิดเผย และคุณมี URL สาธารณะของคุณเป็น: https://your-app-name.herokuapp.comtunnel tunnel จะเข้ารหัสการรับส่งข้อมูลทั้งหมดระหว่างเพียร์และรีเลย์ด้วย TLS หากรีเลย์ใช้ https ไม่มีการเข้ารหัสจากต้นทางถึง ปลายทาง ระหว่างเพื่อนเอง อย่างไรก็ตาม รีเลย์เซิร์ฟเวอร์ไปป์ถูกอ้างว่า ไม่มีพื้นที่เก็บข้อมูล
ไคลเอ็นต์เพียร์สามารถเชื่อมต่อกับเพียร์ที่ให้บริการได้ก็ต่อเมื่อพวกเขาใช้รหัสลับเดียวกัน (TUNNEL_KEY) คีย์นี้ใช้สำหรับการค้นหาเพียร์เป็นหลักในขั้นตอนการถ่ายทอด สำหรับการเชื่อมต่อใหม่ทุกครั้งไปยังพอร์ตภายในเครื่องที่ส่งต่อ ไคลเอ็นต์จะส่งคีย์เซสชันแบบสุ่มไปยังเพียร์ที่ให้บริการ จากนั้นเพียร์จะสร้างการเชื่อมต่อใหม่ที่จุดรีเลย์อื่นโดยใช้คีย์สุ่มนี้เพื่อให้การถ่ายโอนข้อมูลจริงเกิดขึ้น คนนอก ได้แก่ ผู้ไม่ประสงค์ดีซึ่งไม่ทราบ TUNNEL_KEY ไม่ควรขัดขวางขั้นตอนนี้
อย่างไรก็ตาม เพียร์ที่เป็นอันตรายสามารถทำสิ่งต่อไปนี้ได้ เนื่องจากเขารู้ TUNNEL_KEY และ ID โหนดของเพียร์ที่ให้บริการ เขาจึงสามารถเลียนแบบอันหลังได้ ดังนั้นข้อมูลจากเพียร์ที่เชื่อมต่อที่ไม่สงสัยจะถูกส่งต่อไปยังผู้แอบอ้าง ซึ่งจะทำให้เซิร์ฟเวอร์ของแท้หิวโหย การอัปเดต/การใช้งาน tunnel ในอนาคตควรจัดการกับภัยคุกคามนี้โดยใช้การเข้ารหัสคีย์สาธารณะ [ในกรณีนั้น คีย์เซสชันแบบสุ่มที่สร้างขึ้นสำหรับการเชื่อมต่อใหม่ทุกครั้งที่จะส่งต่อ จะสามารถถอดรหัสได้โดยเซิร์ฟเวอร์ของแท้เพียงอย่างเดียว]
เนื่องจาก tunnel นั้นโดยพื้นฐานแล้วเป็นชั้นการขนส่ง จุดข้างต้นไม่ควรท้อใจ เนื่องจากแอปพลิเคชันส่วนใหญ่ เช่น SSH และ IPFS เข้ารหัสข้อมูลที่ชั้นแอปพลิเคชัน การเข้ารหัส tunnel จากต้นทางถึงปลายทางสำหรับการถ่ายโอนข้อมูล ทั้งหมด จะเพิ่มเวลาแฝงเท่านั้น อย่างไรก็ตาม คุณสามารถสร้างอุโมงค์ SSH ได้ตลอดเวลาหลังจากสร้างการเพียร์ระดับต่ำด้วย tunnel หากคุณเลือก
รีเลย์เริ่มต้นที่ใช้โดย tunnel คือ https://ppng.io คุณยังสามารถใช้รีเลย์สาธารณะอื่นๆ จากรายการนี้ หรือโฮสต์อินสแตนซ์ของคุณเองในบริการฟรี เช่น ที่นำเสนอโดย Heroku ไม่จำเป็นต้องพูดว่าในการเชื่อมต่อ เพื่อนสองคนต้องใช้รีเลย์เดียวกัน
หากคุณเลือก คุณยังสามารถเขียนรีเลย์ของคุณเองเพื่อใช้ใน tunnel ได้โดยใช้เครื่องมือง่ายๆ เช่น sertain เพียงตรวจสอบให้แน่ใจว่าบริการรีเลย์ของคุณมี API เดียวกันกับเซิร์ฟเวอร์ไปป์ หากรหัสรีเลย์ของคุณเป็นโอเพ่นซอร์ส คุณสามารถแนะนำรหัสดังกล่าวได้ในการสนทนา
ซ็อคเก็ต ; ipfs p2p พร้อมเปิดใช้งานวงจรรีเลย์ ; ไป-ท่อ-ดูเพล็กซ์ ; ไปป์โตฉัน ; อัปลิงค์ ; localhost.run ; งรก ; อุโมงค์ท้องถิ่น ; sshreach.me ( ทดลองใช้ฟรีในระยะเวลาจำกัดเท่านั้น ); มากกว่า
หมายเหตุ:
tunnel และเซิร์ฟเวอร์ไปป์ คุณสามารถปรับใช้รีเลย์อินสแตนซ์ของคุณเอง แชร์ URL สาธารณะกับเพื่อนของคุณทันที export เดียวกับ TUNNEL_RELAY ภายใน . .bashrc เท่านี้คุณก็พร้อมแล้ว นอกจากนี้ ยังมีเซิร์ฟเวอร์ piping สาธารณะหลายเครื่องที่พร้อมใช้งานเพื่อความซ้ำซ้อนIPFS (เสร็จสิ้น):
การเชื่อมต่อกับ IPFS จะง่ายกว่ามาก:
tunnel -k <secret> ipfs ที่จะเปิดเผย และ tunnel -k <secret> <IPFS_peerID> เพื่อเชื่อมต่อ
สิ่งเหล่านี้จะเปิดตัว IPFS daemon ด้วยตัวเอง หากออฟไลน์อยู่ คำสั่งหลังจะเชื่อมต่อกับเพียร์ที่กำหนดซ้ำ ๆ ทุกๆ 30 วินาที IPFS-peer-ID จะใช้เป็น ID โหนด ดังนั้นเพียร์จึงไม่จำเป็นต้องแชร์ ID โหนดแยกกันอีกต่อไป เส้นทาง repo IPFS ที่ไม่ใช่ค่าเริ่มต้นอาจถูกส่งผ่านด้วยตัวเลือก -r หรือ IPFS_PATH
เอสเอสเอช:
การสร้างอุโมงค์ SSH ระหว่างพอร์ตภายในเครื่องและเพียร์จะง่ายเหมือน:
tunnel -k <secret> ssh เพื่อแสดง &
tunnel -sk <secret> -b <local-port> <peerID>:<peer-port> เพื่อสร้าง
โปรดทราบว่าในขณะที่เชื่อมต่อ ไม่จำเป็นต้องระบุชื่อเข้าสู่ระบบอีกต่อไป ${USER} ของโหนดที่ให้บริการจะถูกใช้เป็นชื่อเข้าสู่ระบบตามค่าเริ่มต้น อย่างไรก็ตาม หากจำเป็น ชื่อล็อกอินที่ไม่ใช่ค่าเริ่มต้นสามารถส่งผ่านได้เสมอโดยใช้ตัวแปรสภาพแวดล้อมหรือตัวเลือก
จีพีจี:
เครื่องเสมือน เช่น ใช้โดย cloud-shells และ dynos ไม่มีที่อยู่ฮาร์ดแวร์ที่ไม่ซ้ำกันและถาวร ดังนั้น ID โหนดจึงเปลี่ยนจากเซสชันหนึ่งไปอีกเซสชันหนึ่งสำหรับ VM ดังกล่าว tunnel ในอนาคตจะมีตัวเลือก -g ซึ่งจะส่งคีย์ส่วนตัวของ GPG ไปที่ tunnel ID โหนดจะถูกสร้างขึ้นจากลายนิ้วมือของคีย์นี้ ซึ่งคล้ายกับสิ่งที่ IPFS ทำ สิ่งนี้จะทำให้ tunnel ปลอดภัยยิ่งขึ้น
อาร์กอน2:
ตัวเลือก [ -a ] เพื่อใช้ argon2 สำหรับการแฮช TUNNEL_KEY ก่อนใช้งาน เพื่อให้ความลับที่อ่อนแอกว่าไม่เสี่ยงเกินไป
กรุณารายงานข้อบกพร่องในประเด็น โพสต์ความคิด ความคิดเห็น แนวคิด กรณีการใช้งาน และคำขอคุณลักษณะของคุณที่การสนทนา แจ้งให้เราทราบว่าสิ่งนี้ช่วยคุณได้อย่างไรหากเป็นเช่นนั้น
โปรดเขียนถึงฉันโดยตรงเกี่ยวกับอะไรก็ได้เกี่ยวกับโครงการนี้
หากสคริปต์เล็กๆ น้อยๆ นี้มีประโยชน์กับคุณ ดาราคงจะเป็นกำลังใจให้ฉันอย่างมาก
ขอบคุณ ! -
