วิธีใช้การเจาะรู UDP สำหรับอุโมงค์ / เซสชัน SSH

ฉันต้องการใช้ Raspberry Pi ในกระท่อมสุดสัปดาห์ของฉัน Raspberry Pi อยู่ที่นั่นเพื่อบันทึกอุณหภูมิและส่งไปยังเซิร์ฟเวอร์ระยะไกลที่มี IP คงที่บันทึกข้อมูลและแสดงไว้ในเว็บไซต์ที่เรียบง่าย

อย่างไรก็ตามสถานการณ์อาจเกิดขึ้นที่ฉันต้องการเปลี่ยนบางสิ่งบางอย่างใน Raspberry Pi ตัวอย่างเช่นการอัปเดตระบบหรือการเปลี่ยนแปลงโปรแกรมที่ส่งข้อมูลไปยังเซิร์ฟเวอร์หรืออะไรก็ตาม

ด้วยการตั้งค่าที่เสนอฉันจะไม่สามารถเชื่อมต่อกับ Raspberry Pi จากด้านนอกของ LAN

หมายเหตุ:ฉันไม่ต้องการเปลี่ยนเครือข่ายและเราเตอร์ที่มีอยู่ไม่มีความสามารถในการส่งต่อพอร์ต dynDNS หรือ VPN

ฉันเพิ่งอ่านมากกว่าการเจาะรู UDP แนวคิดพื้นฐานคือว่าไคลเอนต์ส่งแพคเกจ UDP ไปยังที่อยู่เซิร์ฟเวอร์ที่รู้จัก (เช่นด้วย IP สาธารณะหรือ dynDNS เปิดใช้งาน) ไคลเอนต์ B ซึ่งต้องการเชื่อมต่อกับไคลเอนต์ A ถามเซิร์ฟเวอร์สำหรับ IP สาธารณะและหมายเลขพอร์ตของลูกค้า A.

จากนั้นมันสามารถเชื่อมต่อกับลูกค้า A โดยตรงบน IP สาธารณะและพอร์ตซึ่งเป็นแบบไดนามิก เนื่องจากไคลเอ็นต์ A เชื่อมต่อกับเซิร์ฟเวอร์เป็นครั้งแรกบนพอร์ตที่ใช้ในขณะนี้ NAT จะส่งต่อแพ็คเกจไปยังไคลเอ็นต์ A

ฉันหวังว่าฉันสรุปความคิดถูกต้องมากหรือน้อย ...

ทั้งหมดนี้ฟังดูดี แต่ปัญหาคือว่านี่ไม่ใช่การกักกันเพื่อให้ทำงานกับการเชื่อมต่อ TCP เนื่องจากเราเตอร์สามารถ“ เข้าใจ” การจับมือของการเชื่อมต่อ TCP และหากไม่ได้สร้างขึ้นอย่างถูกต้องมันจะไม่ส่งต่อ แพคเกจ

ดังนั้นฉันจะเปิดเซสชัน SSH จากไคลเอนต์ B ไปยังไคลเอนต์ A โดยไม่มีไคลเอนต์ A นั่งหลังเราเตอร์ที่มี dynDNS, IP สาธารณะแก้ไขหรือความสามารถในการส่งต่อพอร์ต? การใช้เซิร์ฟเวอร์ส่วนกลางที่มีสาธารณะแก้ไข IP หรือชื่อโดเมนอาจเป็นไปได้ยาก

— คริสเตียน
แหล่งที่มา

คุณมีอุปกรณ์ที่ใช้อินเทอร์เน็ตที่สามารถเจาะรู UDP ได้ แต่ไม่ใช่ TCP? รับอุปกรณ์ NAT ที่ดีกว่า

— cpt_fink

ฉันไม่ได้ทำ ssh ด้วย udp แต่นี่คือลิงค์บนzarb.org/~gc/html/udp-in-ssh-tunneling.html

— barlop

ฉันไม่รู้ แต่ฉันถามกูรู ssh พวกเขาบอกว่า ssh สามารถส่งต่อ udp ได้ แต่ถ้ามันทำหน้าที่เหมือน vpn และมีสวิตช์สำหรับมันเขาบอกว่ามัน-wแต่เขาพูดว่า udp มากกว่า tcp (อาจเป็นเพราะเขา รวมถึงความพยายามใด ๆ ที่จะส่งต่อ udp ด้วย ssh), เกี่ยวข้องกับปัญหาต่าง ๆ เช่นเวลาในการตอบสนองสูงและการส่งสิ่งที่คุณไม่ต้องการอีกต่อไป ฉันคิดว่ามันยังคงเป็นสิ่งที่น่าสนใจที่จะลอง ฉันเห็น vpn นี้ผ่าน ssh และ -w พูดถึงที่นี่ด้วยwiki.archlinux.org/index.php/VPN_over_SSH

— barlop

ฉันอยากรู้ว่าทำไมคุณไม่ต้องการเปิดพอร์ตขาเข้า - สิ่งนี้ไม่เหมือนสถานการณ์ที่ต้องมีการรักษาความปลอดภัยที่ยอดเยี่ยม ... หรือมิฉะนั้นคุณสามารถให้ลูกค้า A รักษาการเชื่อมต่อ SSH ขาออกด้วยพอร์ตย้อนกลับเชื่อมโยงกับเซิร์ฟเวอร์ที่ไคลเอ็นต์ B เข้าถึงได้ ด้วยวิธีนี้คุณสามารถเชื่อมต่อผ่านเซิร์ฟเวอร์ตัวกลาง อย่างไรก็ตามข้อตกลงประเภทต่าง ๆ เหล่านี้มีแนวโน้มที่จะล้มเหลวและเป็นสิ่งที่ไม่พึงประสงค์เนื่องจากมีการ จำกัด การเข้าถึงทางกายภาพเพื่อคัดแยกเมื่อเกิดข้อผิดพลาด

— kabadisha

คำตอบ:

`pwnat`

".. มันไม่สำคัญที่จะเริ่มต้นการเชื่อมต่อกับเพื่อนหลัง NAT "

".. เกือบทุกการใช้งานNAT ปฏิเสธที่จะส่งต่อทราฟฟิกขาเข้าที่ไม่สอดคล้องกับคำขอขาออกล่าสุดที่ตรงกัน "

".. pwnatเครื่องมือนี้เป็นการนำGNU / Linuxไปใช้อย่างเดียวแบบสแตนด์อโลนสำหรับการแวะผ่าน NAT แบบอิสระหลังจากติดต่อกับเซิร์ฟเวอร์ที่อยู่ด้านหลัง NATมันจะสร้างช่องสัญญาณที่มีTCP ความหมายโดยใช้แพ็คเก็ต UDPรองรับทั้งไคลเอนต์และเซิร์ฟเวอร์ที่อยู่เบื้องหลัง NAT (หากหนึ่งใน NATs อนุญาตให้ส่งข้อความICMP [กำหนดเอง] ปลอมได้การใช้งานนี้มีเป้าหมายผู้ใช้ปลายทาง "

  
การใช้งาน: ./pwnat <-s | -c> <args>

  โหมดไคลเอนต์ -c
    <args>: [local ip] <local port> <proxy host> [proxy port (def: 2222)] <remote host> <remote port>

  โหมดเซิร์ฟเวอร์
    <args>: [local ip] [พอร์ตพร็อกซี (def: 2222)] [[โฮสต์ที่ได้รับอนุญาต]: [พอร์ตที่อนุญาต] ... ]

  -6 ใช้ IPv6  
  -v แสดงเอาต์พุตการดีบัก (มากถึง 2)  
  แสดงความช่วยเหลือและออก  

ตัวอย่าง:  

    ฝั่งเซิร์ฟเวอร์อนุญาตให้ทุกคนพร็อกซี:
      ./pwnat -s

    ลูกค้าที่ต้องการเชื่อมต่อกับ google.com:80:
      ./pwnat -c 8000 <pwnat.server.com> google.com 80
    จากนั้นไปที่ http: // localhost: 8000 เพื่อเยี่ยมชม google!

"ความคิดที่สำคัญสำหรับการเปิดใช้งานเซิร์ฟเวอร์ที่จะเรียนรู้ที่อยู่ IP ของลูกค้าคือสำหรับเซิร์ฟเวอร์ไปเป็นระยะ ๆ ส่งข้อความไปยังคงที่อยู่ IP ที่รู้จักกัน.วิธีการที่ง่ายที่สุดใช้ข้อความคำขอ ICMP ECHO ไปยังที่อยู่ IP ไม่ได้ถูกจัดสรรเช่น 1.2.3.4 เนื่องจาก 1.2.3.4 ไม่ได้รับการจัดสรร ICMP REQUEST จะไม่ถูกกำหนดเส้นทางโดยเราเตอร์หากไม่มีเส้นทางเริ่มต้น "

"ในฐานะที่เป็นผลมาจากข้อความที่ส่งไปยัง 1.2.3.4 การNAT จะช่วยให้การกำหนดเส้นทางการตอบในการตอบสนองต่อการร้องขอนี้. เชื่อมลูกค้าแล้วจะปลอมตอบกลับดังกล่าว.เฉพาะลูกค้าจะส่งข้อความ ICMP แสดงให้เห็นTTL_EXPIRED. ดังกล่าว ข้อความอาจถูกส่งอย่างถูกต้องโดยเราเตอร์อินเทอร์เน็ตและที่อยู่ผู้ส่งไม่คาดว่าจะตรงกับ IP เป้าหมายของเซิร์ฟเวอร์ "

" ฟังเซิร์ฟเวอร์ (ปลอม) การตอบ ICMPและเมื่อได้รับ, เริ่มต้นการเชื่อมต่อไปยังผู้ส่ง IP ได้ระบุไว้ในการตอบกลับ ICMP. หากลูกค้าใช้ที่อยู่ IP routable ทั่วโลกนี้อยู่ unproblematic ทั้งหมดและทั้งTCP หรือ UDP สามารถนำมาใช้ เพื่อสร้างการเชื่อมต่อแบบสองทิศทางถ้าลูกค้าฟังบนพอร์ตก่อนตกลง. "

"(ในกรณีที่ไม่มีพอร์ตที่ตกลงไว้ล่วงหน้าหมายเลขพอร์ตสามารถสื่อสารได้ในกรณีส่วนใหญ่ซึ่งเป็นส่วนหนึ่งของส่วนบรรจุของ ICMP ECHO RESPONSE)"

ที่มา: http://samy.pl/pwnat.pdf
https://github.com/samyk/pwnat

— เสียง
แหล่งที่มา

pwnat นั้นแทบจะไม่สามารถใช้งานได้แม้แต่ localhost กับการเชื่อมต่อ localhost ฉันสามารถส่งและรับแพ็คเก็ตบางส่วน แต่สำหรับการสร้างการเชื่อมต่อที่แข็งแกร่งมันไม่ได้มีประโยชน์มาก

— สกอตต์

@Scott มันเป็นแฮ็คที่น่าสนใจ แต่จริงๆแล้วมันเป็นเพียงการพิสูจน์แนวคิดตามการใช้งานในทางที่ผิดและการละเมิดของโปรโตคอลเครือข่ายเช่น ICMP ฉันจะไม่พึ่งพามัน มันเก่าและไม่มีสีและฉันจะไม่แนะนำให้ใช้ ฉันไม่ได้พูดถึงมันหากคำถามไม่ได้ระบุการเจาะรู UDP โดยเฉพาะ หากคุณต้องการความน่าเชื่อถือลองเชื่อมต่ออุโมงค์ VPN

— เสียง

ฉันไม่ได้บ่น แต่ฉันคิดว่า "การแก้ปัญหานี้ไม่ได้มีไว้สำหรับการใช้งานในสภาพแวดล้อมการผลิต" เป็นข้อมูลที่มีประโยชน์สำหรับทุกคนที่มาที่นี่เพื่อมองหาโซลูชันที่มีความเสถียร

— สกอตต์

@Scott มันไม่ใช่สำหรับใช้ในสภาพแวดล้อมแบบนั้น ผลิตภัณฑ์ที่เป็นกรรมสิทธิ์จำนวนมากใช้เทคนิคเหล่านี้ อย่างไรก็ตามมีข้อมูลเพียงพอที่นี่สำหรับผู้ใช้ในการตัดสินใจของตัวเอง ฉันไม่แนะนำ แต่ฉันใช้อุโมงค์ VPN ในทางกลับกันเครือข่ายบางเครือข่ายจะกรองปริมาณการใช้งาน VPN ดังนั้นคุณต้องดำเนินการเป็นกรณี ๆ ไป คุณต้องการความช่วยเหลือในการผ่าน NAT เราเตอร์หรือไม่?

— เสียง

ฉันมีวิธีแก้ปัญหาที่ใช้การได้ในปัจจุบันโดยใช้ reverse ssh tunnels เพื่อเชื่อมโยงเครื่อง NAT สองเครื่อง อย่างไรก็ตามมันต้องใช้เครื่อง "พ่อค้าคนกลาง" ที่มี IP แบบคงที่หรือผู้ที่ฉันสามารถกำหนดค่าการส่งต่อพอร์ตบนเราเตอร์ สิ่งนี้จะทำให้ฉันสามารถตัดพ่อค้าคนกลางออกได้ โอ้ดี

— สกอตต์

นี่คือโซลูชันสองสามข้อ:

คุณสามารถตั้งค่า Raspberry Pi ของคุณเพื่อเชื่อมต่อกลับไปยังเซิร์ฟเวอร์ OpenVPN และคุณจะสามารถเข้าถึงได้ตลอดเวลา

คุณสามารถดู PageKite ตรวจสอบhttps://pagekite.net/wiki/Howto/SshOverPageKite/

— Obay
แหล่งที่มา

สิ่งนี้เกี่ยวข้องกับ"การเจาะรู UDP" อย่างไร

— เสียง

มันเป็นวิธีที่ค่อนข้างจะสกปรก แต่ใช้งานง่าย แต่สิ่งที่เกี่ยวกับการใช้ netcat? บน Raspberry Pi คุณสามารถสร้างสคริปต์ที่ลูปคำสั่ง:

nc <public_ip> <port1> | sh | nc <public_ip> <port2>

บนโฮสต์ท้องถิ่นของคุณให้ทำ:

nc -l <port1>

และ:

nc -l <port2>

คุณจะสามารถพิมพ์คำสั่งในอินสแตนซ์แรกและดูการตอบสนองในครั้งที่สอง

— พอล
แหล่งที่มา

สิ่งนี้เกี่ยวข้องกับ"การเจาะรู UDP" อย่างไร

— เสียง

NAT สำรวจผ่านวิธีนี้อย่างไร

— ZEE