การหมดเวลาการเชื่อมต่อ UDP หมายถึงอะไรจริงๆ?


18

เนื่องจาก UDP เป็นโปรโตคอลที่ไม่มีการเชื่อมต่อฉันจึงสับสนกับการตั้งค่าใน Sonicwall Firewall ของฉันสำหรับ "UDP Connection Timeout" มันตั้งไว้ที่ค่าเริ่มต้นของ 30 วินาที - แต่สิ่งที่หมดเวลาหลังจาก 30 วินาที?

WTF?

นี่คือสถานการณ์จริงของฉัน: ฉันมีเซิร์ฟเวอร์ NTP ในกลุ่ม ntp.org ที่ให้บริการการสืบค้นประมาณ 3000 ครั้งต่อนาที สิ่งนี้ทำให้เครียดกับ SOHO เกรด TZ-200 ของฉัน - ไม่ใช่ในแง่ของแบนด์วิดธ์; แต่ในแง่ของจำนวนการเชื่อมต่อที่ผ่านมา ฉันสงสัยว่าการเชื่อมต่อ UDP จะ 'คงอยู่' ใน SonicWall หรือไม่ ถึงแม้ว่าพวกเขากำลังเชื่อมต่อ (ตามคำนิยาม)

สิ่งที่ฉันหายไปที่นี่? SonicWall หมายถึงอะไรเมื่อพูดถึง "หมดเวลาการเชื่อมต่อ UDP"?


ไฟร์วอลล์มักจะอนุญาตให้มีแพ็กเก็ตสำหรับการเชื่อมต่อที่สร้างขึ้นโดยเครื่องภายในไฟร์วอลล์ แต่ UDP ไม่มีการเชื่อมต่อ ดังนั้นทางเลือกคืออนุญาตให้ใช้แพ็คเก็ต UDP ทั้งหมดปิดกั้นแพ็กเก็ต UDP ทั้งหมดหรือลองเดาว่า "การเชื่อมต่อ UDP" นั้นอนุญาตให้ใช้แพ็คเก็ตที่เป็นส่วนหนึ่งของ "การเชื่อมต่อ" เหล่านั้นเท่านั้น ผู้จำหน่ายไฟร์วอลล์ (?) ทั้งหมดใช้แนวทางล่าสุด
253751

ในฐานะที่เป็น Immibis ได้อธิบาย เนื่องจากการแปลที่อยู่เครือข่ายหรือ NAT เราเตอร์เกตเวย์อินเทอร์เน็ต / เครือข่ายย่อยจะอนุญาต TCP เท่านั้น (การรับส่งข้อมูลทั้งหมดเป็น TCP) ซึ่งไคลเอ็นต์บนเครือข่ายย่อยเริ่มการเชื่อมต่อ เพราะไม่มีทางที่จะกำหนดพอร์ตสำหรับ NAT หากการเชื่อมต่อเข้ามา เราเตอร์รู้ได้อย่างไรว่าใครจะส่งไปที่ UDP ไม่มีการเชื่อมต่อดังนั้นเราเตอร์จึงจัดการกับคำขอ UDP ที่ส่งเข้ามาได้อย่างไร วิธีหนึ่งคือการติดตามแพ็กเก็ต UDP ขาออก
งานฝีมือจอมพล

หากคุณกำลังโฮสต์เซิร์ฟเวอร์คุณควรส่งต่อพอร์ตที่คุณคาดหวังว่าจะได้รับการเชื่อมต่อ แต่ต้องเตรียมพร้อมทุกอย่าง
เรือจอมพลฝีมือ

คำตอบ:


16

ในขณะที่ไม่มี "การเชื่อมต่อ" อย่างเป็นทางการกับ UDP ยังมีข้อตกลงที่ลูกค้าส่งคำขอและคาดว่าจะได้รับการตอบกลับด้วย IP ต้นทางและพอร์ตที่สลับกับ IP ปลายทางและพอร์ต Destinatoin

ดังนั้นจึงควรคิดว่าแพ็กเก็ตที่มีการรวมกันของแหล่งที่มา IP / แหล่งที่มา / ปลายทาง IP / ปลายทางพอร์ตและการรวมกันที่สอดคล้องกับแหล่งที่มาและปลายทางเปลี่ยนรูปแบบส่วนหนึ่งของ "การเชื่อมต่อ" สิ่งนี้อนุญาตให้ใช้กฎเช่น "การเชื่อมต่อขาออกเท่านั้น" ที่จะนำไปใช้กับ UDP และอนุญาตให้ใช้การแปลย้อนกลับเพื่อนำไปใช้กับแพ็กเก็ตตอบกลับ

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

โดยหลักการแล้วมันเป็นไปได้ที่จะสร้างกล่อง NAT ที่ใช้วิธีไร้สัญชาติสำหรับการส่งต่อพอร์ตในขณะที่รักษาวิธีการที่เป็นรัฐสำหรับการเชื่อมต่อขาออก แต่มันง่ายกว่าที่จะใช้ NAT แบบไร้รัฐสำหรับทุกสิ่ง

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


2
ขอบคุณสำหรับคำตอบที่ดี Peter! ในกรณีของฉัน SonicWall อนุญาตให้ฉันลด UDP "การเชื่อมต่อหมดเวลา" ในกฎไฟร์วอลล์เฉพาะดังนั้นฉันจะลดกฎของนโยบาย NTP เป็น 5 วินาที (จากค่าเริ่มต้น 30)
Jon Wadsworth

1
หมายเหตุ: หลังจากทำเช่นนั้นฉันเห็น 'การเชื่อมต่อทั้งหมด' ตามที่รายงานโดย Sonicwall ลดลงจาก ~ 1500 ถึง ~ 400 ที่สมบูรณ์แบบ! ขอบคุณอีกครั้งสำหรับคำตอบที่ดี
Jon Wadsworth

1
โปรดทราบว่าโปรโตคอลการสตรีมส่วนใหญ่ใช้ UDP ซึ่งรวมถึงส่วนสื่อของ VOIP (หลังจากที่มีการเจรจาต่อรองโดยใช้ SIP) การมีการหมดเวลาสั้น ๆ นั้นอาจทำให้เกิดปัญหาได้หากไม่มีทราฟฟิก (เช่นพักสายทั้งสองข้างปิดเสียง ฯลฯ ) เนื่องจากโทรศัพท์ VOIP ทั้งหมด (แข็งหรืออ่อน) นั้นยอดเยี่ยมในการเจรจาเชื่อมต่อสื่อใหม่หากพอร์ตหลุด . คนอื่นใช้ 'Keep alive' โดยส่งสัญญาณเล็ก ๆ เป็นระยะ ๆ ซึ่งอาจห่างกันมากกว่า 5 วินาที
Chuck van der Linden

11

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


ขอบคุณรอน คุณสามารถแสดงความคิดเห็นในตารางการเชื่อมต่อนั้นเกี่ยวกับการเชื่อมต่อขาเข้าได้หรือไม่? เนื่องจากเซิร์ฟเวอร์ NTP ของฉันอยู่ด้านในจึงไม่จำเป็นต้อง 'เปิดประตูไว้' สำหรับการเชื่อมต่อขาเข้าเหล่านั้นเนื่องจากเซิร์ฟเวอร์ของฉันด้านในสามารถกลับออกไปยังแหล่งที่มาได้เสมอ (ฉันมีขาออกแบบเปิดกว้าง กฎ) ขอบคุณสำหรับคำตอบด่วน!
Jon Wadsworth

3
ตารางการเชื่อมต่อถูกสร้างขึ้นโดยไม่คำนึงถึงทิศทางของการเชื่อมต่อและจริง ๆ แล้วจะใช้ทันทีสำหรับแพ็คเก็ตตอบกลับที่มาจากเซิร์ฟเวอร์ของคุณผ่านไฟร์วอลล์ที่กลับสู่การสอบถาม ไฟร์วอลล์กำลังรักษา tuple เป็น (src ip, src พอร์ต, dst ip, พอร์ต dst) เพื่อเชื่อมโยงแบบสอบถามเริ่มต้นกับการตอบสนอง เนื่องจากไม่มีเซมาฟอร์จริง ๆ เพื่อระบุถึงไฟร์วอลล์ที่เซสชัน UDP เฉพาะเสร็จสิ้นและซ็อกเก็ตได้ปิดค่าหมดเวลาใช้งานสิ้นสุดลง
rnxrx

2

เซิร์ฟเวอร์ NTP ของคุณอยู่หลัง NAT (ไฟร์วอลล์) UDP นั้นเชื่อมต่อจากมุมมองของแอปพลิเคชันและระบบปฏิบัติการและสำหรับอุปกรณ์เครือข่ายส่วนใหญ่ไปพร้อมกัน

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

ในทางทฤษฎีแล้ว NAT รู้ว่าพอร์ตภายนอกจะเป็นพอร์ตที่รู้จักกันดีของ NTP แต่ดูเหมือนว่าไฟร์วอลล์ของคุณจะไม่รองรับ หากนี่เป็นเพียงการใช้งาน UDP ผ่านไฟร์วอลล์นี้คุณสามารถตั้งค่าการหมดเวลาการเชื่อมต่อเป็นจำนวนที่น้อยลง อีกทางหนึ่งถ้ามันอนุญาตให้คุณตั้งค่าโดยพอร์ตแอปพลิเคชันคุณสามารถตั้งค่าเป็นเวลาที่น้อยลง (1 วินาทีพูด) สำหรับพอร์ตเฉพาะนั้น


1
การหมดเวลาไม่เฉพาะเจาะจงกับ NAT ไฟร์วอลล์ที่ไม่ระบุชื่อใด ๆ จะมีหนึ่งอัน
user1686

ไฟร์วอลล์ไม่ได้ทำ NAT แทนที่จะพยายามกรองแพ็กเก็ตที่กำลังเปลี่ยนผ่าน NAT ดังนั้นความสัมพันธ์ระหว่างเราเตอร์และ NAT
เรือจอมพลฝีมือ

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.