อะไรเป็นสาเหตุให้ส่งแฟล็ก TCP / IP reset (RST)

ฉันกำลังพยายามหาคำตอบว่าทำไมการเชื่อมต่อ TCP / IP ของแอปของฉันจึงมีอาการสะอึกทุกๆ 10 นาที (แน่นอนภายใน 1-2 วินาที) ฉันใช้งาน Wireshark และพบว่าหลังจากไม่มีการใช้งาน 10 นาทีปลายอีกด้านหนึ่งกำลังส่งแพ็กเก็ตพร้อมชุดค่าสถานะรีเซ็ต (RST) การค้นหาของ Google บอกฉันว่า "ค่าสถานะ RESET หมายความว่าผู้รับเริ่มสับสนและต้องการยกเลิกการเชื่อมต่อ" แต่นั่นเป็นเพียงรายละเอียดเล็กน้อยที่ฉันต้องการ อะไรคือสาเหตุนี้ และเป็นไปได้ไหมที่เราเตอร์บางตัวในระหว่างทางจะรับผิดชอบหรือสิ่งนี้จะมาจากจุดสิ้นสุดอื่นเสมอ?

แก้ไข:มีเราเตอร์ (โดยเฉพาะ Linksys WRT-54G) นั่งอยู่ระหว่างคอมพิวเตอร์ของฉันและปลายทางอื่น ๆ - มีสิ่งใดที่ฉันควรค้นหาในการตั้งค่าเราเตอร์หรือไม่

'เราเตอร์' สามารถทำอะไรก็ได้โดยเฉพาะ NAT ซึ่งอาจเกี่ยวข้องกับการรบกวนการรับส่งข้อมูล ...

เหตุผลหนึ่งที่อุปกรณ์จะส่ง RST เพื่อตอบสนองต่อการรับแพ็คเก็ตสำหรับซ็อกเก็ตที่ปิดอยู่

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

เรียกใช้ packet sniffer (เช่น Wireshark) บนเครื่องเพียร์เพื่อดูว่าเป็นเพียร์ที่ส่ง RST หรือคนที่อยู่ตรงกลาง

ฉันใช้เวลาพอสมควรในการแก้ไขปัญหานี้ ไม่มีวิธีแก้ปัญหาที่เสนอมา ปรากฎว่าผู้ดูแลระบบของเรากำหนด IP แบบคงที่เดียวกันให้กับเซิร์ฟเวอร์ที่ไม่เกี่ยวข้องสองเครื่องที่อยู่ในกลุ่มต่าง ๆ โดยไม่ได้ตั้งใจ แต่นั่งอยู่บนเครือข่ายเดียวกัน ผลลัพธ์สุดท้ายคือการเชื่อมต่อ vnc ลดลงเป็นระยะ ๆ เบราว์เซอร์ที่ต้องรีเฟรชหลายครั้งเพื่อดึงข้อมูลหน้าเว็บและสิ่งแปลก ๆ อื่น ๆ

ไฟร์วอลล์บางตัวทำเช่นนั้นหากไม่มีการเชื่อมต่อเป็นเวลา x จำนวนนาที ISP บางรายตั้งค่าเราเตอร์ให้ทำเช่นนั้นด้วยเหตุผลหลายประการเช่นกัน

ในวันนี้และอายุคุณจะต้องจัดการ (สร้างใหม่ตามความจำเป็น) อย่างสง่างาม

RST ถูกส่งโดยด้านข้างทำการปิดที่ใช้งานอยู่เนื่องจากเป็นด้านที่ส่ง ACK สุดท้าย ดังนั้นหากได้รับ FIN จากด้านข้างทำการปิดแบบพาสซีฟในสถานะที่ไม่ถูกต้องมันจะส่งแพ็กเก็ต RST ซึ่งระบุอีกด้านหนึ่งว่าเกิดข้อผิดพลาด

หากมีเราเตอร์ที่ทำ NAT โดยเฉพาะเราเตอร์ระดับล่างที่มีทรัพยากรน้อยเครื่องจะกำหนดอายุเซสชัน TCP ที่เก่าที่สุดก่อน ในการทำเช่นนี้จะตั้งRSTค่าสถานะในแพ็กเก็ตที่บอกสถานีรับอย่างมีประสิทธิภาพให้ปิดการเชื่อมต่อ (อย่างไม่สมศักดิ์ศรี) สิ่งนี้ทำเพื่อประหยัดทรัพยากร

สิ่งหนึ่งที่ควรระวังคือไฟร์วอลล์ Linux netfilter จำนวนมากถูกกำหนดค่าไม่ถูกต้อง

หากคุณมีสิ่งที่ต้องการ:

-A FORWARD -m state --state RELATED, ESTABLISHED -j ACCEPT

-A ไปข้างหน้า -p tcp -j ปฏิเสธ - ปฏิเสธด้วย tcp-reset

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

การเรียงลำดับใหม่มีแนวโน้มโดยเฉพาะอย่างยิ่งกับเครือข่ายไร้สาย

สิ่งนี้ควรเป็น:

-A FORWARD -m state --state RELATED, ESTABLISHED -j ACCEPT

-A FORWARD -m state --state ไม่ถูกต้อง -j DROP

-A ไปข้างหน้า -p tcp -j ปฏิเสธ - ปฏิเสธด้วย tcp-reset

โดยทั่วไปทุกเวลาที่คุณมี:

... -m รัฐ - รัฐที่เกี่ยวข้องก่อตั้ง -j ยอมรับ

ทันทีควรตามด้วย:

... -m state --state ไม่ถูกต้อง -j DROP

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

เนื่องจากมีกระบวนการอื่นในเครือข่ายที่ส่ง RST ไปยังการเชื่อมต่อ TCP ของคุณ

โดยปกติ RST จะถูกส่งในกรณีต่อไปนี้

• กระบวนการปิดซ็อกเก็ตเมื่อเปิดใช้งานซ็อกเก็ตโดยใช้ตัวเลือก SO_LINGER
• ระบบปฏิบัติการกำลังทำการล้างทรัพยากรเมื่อกระบวนการของคุณออกโดยไม่ต้องปิดซ็อกเก็ต

ในกรณีของคุณดูเหมือนว่ากระบวนการกำลังเชื่อมต่อการเชื่อมต่อของคุณ (พอร์ต IP +) และส่ง RST ต่อไปหลังจากสร้างการเชื่อมต่อ