Netcat หยุดฟังการรับส่งข้อมูล UDP

ฉันใช้ netcat ในเครื่อง Linux บางตัว (ดูคำถามอื่น ) แต่เห็นพฤติกรรมที่ไม่คาดคิด

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

ทันเนลจากเครื่องของฉันไปยังเซิร์ฟเวอร์ทำงานได้อย่างสมบูรณ์อย่างไรก็ตามในฝั่งเซิร์ฟเวอร์อินสแตนซ์ของ netcat ที่กำลังรับฟังการตอบสนองจากเซิร์ฟเวอร์ UDP จะปิดฟังหลังจากได้รับการตอบกลับครั้งแรก ดังนั้นฉันสามารถส่งคำขอและได้รับการตอบกลับ 1 ครั้ง แต่การร้องขอใด ๆ ที่ตามมาจะทำให้มันเป็นไปได้ที่เซิร์ฟเวอร์ก็โอเค แต่การตอบกลับจะไม่ได้รับ ใช้ netstat ฉันจะเห็นว่าก่อนที่จะได้รับการตอบสนอง netcat กำลังฟัง แต่พอร์ตจะถูกปิดหลังจากที่ได้รับการตอบสนอง

อินสแตนซ์ netcat บนเครื่องของฉันดูเหมือนว่าจะจัดการทุกอย่างได้ดี ทั้งสองเครื่องกำลังเรียกใช้ netcat v1.10-38 ความคิดใด ๆ ที่เกิดขึ้น?

มีหลายสิ่งที่เรียกว่า netcat ubuntu ยังมี / etc / ทางเลือก symbol-link-hackery สำหรับมัน

ฉันคิดว่าส่วนหนึ่งของปัญหาของคุณคือ UDP ไม่ทำเซสชัน ฉันได้คัดลอกไฟล์ /usr/share/doc/netcat-traditional/README.gz ไว้ด้านล่างซึ่งใช้อธิบายได้ดี

การเชื่อมต่อ UDP ถูกเปิดแทน TCP เมื่อระบุ -u สิ่งเหล่านี้ไม่ใช่ "การเชื่อมต่อ" ต่อเนื่องจาก UDP เป็นโปรโตคอลการเชื่อมต่อที่ไม่ได้ใช้งานแม้ว่า netcat จะใช้กลไก "ซ็อกเก็ตที่เชื่อมต่อ UDP" ภายในซึ่งเมล็ดส่วนใหญ่รองรับ แม้ว่า netcat อ้างว่าการเชื่อมต่อ UDP ขาออกเป็น "เปิด" ทันทีไม่มีการส่งข้อมูลจนกว่าจะมีบางสิ่งอ่านจากอินพุตมาตรฐาน หลังจากนั้นก็เป็นไปได้ที่จะตรวจสอบว่ามีเซิร์ฟเวอร์ UDP จริงๆที่ปลายอีกด้านหนึ่งหรือไม่และบ่อยครั้งที่คุณไม่สามารถบอกได้ โปรโตคอล UDP ส่วนใหญ่ใช้การหมดเวลาและลองอีกครั้งเพื่อทำสิ่งต่าง ๆ และในหลายกรณีจะไม่รบกวนการตอบรับเลยดังนั้นคุณควรระบุการหมดเวลาและหวังว่าจะดีที่สุด

ตกลงบางทีนั่นอาจไม่ใช่คำอธิบายที่ดีทั้งหมด แต่เป็นสิ่งที่ฉันสามารถหาได้

หากคุณยังไม่มีคุณอาจต้องการทดลองใช้ตัวเลือก netcat ใด ๆ ที่คุณสามารถพบได้ซึ่งจะเกี่ยวกับการรอ ... คุณได้ทดลองใช้:

• ใช้ -l และ -u เพื่อให้แน่ใจว่าคุณอยู่ในโหมด "กำลังฟัง"

• -vv เพื่อดูว่าเกิดอะไรขึ้น

• -q -1 ... ซึ่งควร "รอตลอดไป" แม้หลังจากได้รับ EOF (หวังว่าจะฟังอีกครั้ง?)

คุณสามารถใช้socatสำหรับการที่ มันมีตัวเลือกที่ดีมากfork:

fork หลังจากสร้างการเชื่อมต่อแล้วให้จัดการช่องสัญญาณในกระบวนการลูกและทำให้กระบวนการหลักพยายามสร้างการเชื่อมต่อมากขึ้นไม่ว่าจะโดยการฟังหรือโดยการเชื่อมต่อในลูป (ตัวอย่าง)

ลูกค้า (ใช่สิ่งนี้คุณเรียกใช้จากลูกค้า):

$ ssh -L 7753:localhost:7753 YourServer.com "/usr/bin/socat tcp4-listen:7753,reuseaddr,fork UDP:8.8.8.8:53"

ลูกค้า:

$ sudo socat udp4-listen:53,reuseaddr,fork tcp:localhost:7753

$ dig @127.0.0.1 google.com