รีเลย์ VPN หยุดรับ SSH: ขีดจำกัดตัวอธิบายไฟล์
ทราฟฟิกในอุโมงค์ยังไหลอยู่ ขณะที่รีเลย์ socat ข้างหลังปฏิเสธเซสชันใหม่ ติดตามเส้นทาง แล้วอ่านขีดจำกัดที่สืบทอดบน PID ที่ยังทำงานอยู่
แฮนด์เชก WireGuard ยังคงสำเร็จ peer ยังแสดงปลายทางล่าสุด แต่เซสชัน SSH ใหม่ผ่านรีเลย์ข้างหลังกลับค้างโดยไม่มีแบนเนอร์ การรวมกันนี้ออกจากอุโมงค์และชี้ไปที่โปรเซสที่รับซ็อกเก็ต รีเลย์อย่าง socat อยู่ในเส้นทางของแอปพลิเคชันพร้อมงบตัวอธิบายไฟล์ของตัวเอง ลูกหลานของตัวเอง และขีดจำกัดที่สืบทอดมาของตัวเอง การเดินด้านล่างเริ่มที่ไคลเอนต์และหยุดที่องค์ประกอบแรกที่ไม่สามารถเปิดซ็อกเก็ตเพิ่มได้
ติดตามเส้นทางก่อนเปลี่ยนตัวเลข
ติดตามคำขอเดียวที่ล้มเหลวแทนการคิดถึงอุโมงค์ทั้งเส้น ไคลเอนต์เขียนเข้าอุโมงค์ เดมอน VPN ถอดรหัสและกำหนดเส้นทาง และรีเลย์รับที่อีกด้านหนึ่ง แต่ละขั้นใช้ตัวอธิบายไฟล์ และตัวที่มักหมดคือตัวสุดท้าย
เริ่มจากคำขอที่คุณสร้างซ้ำได้และวัดเวลา ถ้าแฮนด์เชก TCP สำเร็จแต่ไม่มีแบนเนอร์ของแอปพลิเคชันมา รีเลย์รับซ็อกเก็ตไปแล้วและไปติดอยู่ในลูกหรือขาขึ้นของมัน ถ้าแฮนด์เชกเองไม่เคยสำเร็จ สาเหตุคือการกำหนดเส้นทาง ไฟร์วอลล์ หรือสถานะตัวรับฟัง ไม่ใช่เพดานตัวอธิบายไฟล์ บันทึกว่าคุณเห็นรูปแบบใดในสองแบบ เพราะมันชี้ไปที่โปรเซสต่างกัน
นับฮอปที่ทำงานซ้ำด้วย ตัวรับฟังที่แยกสาขาจะส่งซ็อกเก็ตที่รับมาแต่ละตัวให้ลูกที่เก็บสำเนาของตัวเอง ดังนั้นยอดรวมจริงเป็นสมบัติของทั้งต้นไม้ ไม่ใช่แค่พ่อแม่
อ่านขีดจำกัดที่รีเลย์สืบทอดมา
ขีดจำกัดเดียวที่สำคัญเป็นของโปรเซสที่กำลังทำงาน และถูกกำหนดโดยสิ่งที่ปล่อยโปรเซสนั้น การพิมพ์ ulimit -n ในเชลล์อธิบายเชลล์ ถามผู้จัดการบริการว่าใช้อะไร แล้วยืนยันบน PID
systemctl show -p MainPID -p LimitNOFILE vpn-relay.service
cat /proc/$(systemctl show -p MainPID --value vpn-relay.service)/limits
ไฟล์ limits พิมพ์เพดานแบบนุ่มและแบบแข็งตามที่โปรเซสมองเห็น ค่านุ่มต่ำใต้ค่าแข็งที่เผื่อไว้มากหมายความว่าเดมอนได้รับอนุญาตให้ยกเพดานของตัวเอง และบางตัวทำเช่นนั้นตอนเริ่มต้น ค่านุ่มต่ำที่เท่ากันหมายความว่าไฟล์ unit เป็นต้นทาง
drop-in โหลดตามลำดับพจนานุกรมและไฟล์ที่มาทีหลังชนะ ดังนั้น systemctl cat vpn-relay.service คือมุมมองที่เชื่อถือได้ว่าอะไรมีผล การแก้ไฟล์ที่ผู้จัดการไม่เคยอ่านคือสาเหตุที่พบบ่อยที่สุดที่ตัวเลขที่เพิ่มขึ้นไม่มีผล
แยกภาวะพร้อมกันแบบคงที่ออกจากสถานะที่ค้างอยู่
สองโปรเซสอาจชนเพดานเดียวกันด้วยเหตุผลที่ไม่เกี่ยวข้องกัน และวิธีแก้ต่างกัน ความต้องการที่ตามเซสชันพร้อมกันที่มีประโยชน์เป็นคำถามเรื่องความจุ การเติบโตที่ดำเนินต่อหลังงานจบคือการรั่วไหลหรือชุดเซสชันที่ไม่มีใครปิด
วัดตอนว่าง ตอนพีคปกติ และอีกครั้งไม่กี่นาทีหลังโหลดหยุด การนับรายการที่เปิดอยู่ด้วย ls /proc/PID/fd | wc -l เทียบกับขีดจำกัดนุ่มบอกช่องว่าง และจำนวนที่ต่ำกว่าเพดานหนึ่งหรือสองคือการหยุดแบบแข็ง ไม่ใช่เส้นทางที่ช้า
เมื่อจำนวนไม่ยอมลด ให้ดูสถานะซ็อกเก็ตแทนยอดรวม ตัวอธิบายไฟล์ที่ค้างใน CLOSE_WAIT หมายความว่า peer ปิดแล้วแต่ฝั่งคุณไม่เคยปิด ซึ่งเป็นข้อบกพร่องในวงจรชีวิตแอปพลิเคชันที่ขีดจำกัดที่ใหญ่ขึ้นเพียงเลื่อนออกไป จำกัดโมเดลลูกด้วย รีเลย์ที่แยกสาขาโดยไม่มีเพดานลูกพร้อมกันจะหมดตัวอธิบายไฟล์ ช่องโปรเซส และหน่วยความจำพร้อมกัน
ตรวจสอบค่าใหม่บนโปรเซสที่ยังทำงานอยู่
หลังแก้ unit ให้โหลดผู้จัดการใหม่และรีสตาร์ตบริการ เพราะการโหลดใหม่อย่างเดียวไม่เคยแทนที่ขีดจำกัดที่โปรเซสที่กำลังทำงานสืบทอดไปแล้ว ตรวจสอบบนโปรเซสที่ให้บริการทราฟฟิกจริง
systemctl daemon-reload
systemctl restart vpn-relay.service
awk '/Max open files/ {print}' /proc/$(systemctl show -p MainPID --value vpn-relay.service)/limits
ss -tnp state established '( sport = :2222 )' | wc -l
บรรทัด awk คืนคู่ใหม่ ถ้ายังแสดงคู่เก่า drop-in ที่คุณแก้ไม่ใช่ตัวที่ถูกโหลด จำนวน ss คือการตรวจโหลดของคุณ ดังนั้นเปิดจำนวนเซสชันที่คาดไว้และดูมันไต่ขึ้น จำนวนที่ยังเพิ่มขึ้นหลังเซสชันเหล่านั้นปิดหมายความว่าขีดจำกัดไม่เคยเป็นปัญหาทั้งหมด
ทุกการเพิ่มขึ้นมากมีข้อควรระวังหนึ่งข้อ แอปพลิเคชันที่สำรวจด้วย select() ไม่สามารถเฝ้าดูตัวอธิบายไฟล์ที่สูงกว่า FD_SETSIZE ซึ่งคือ 1024 ในการบิลด์ทั่วไป ดังนั้นเพดานที่ยกเกินกว่านั้นอาจสร้างความล้มเหลวที่ดูไม่เกี่ยวข้อง เอกสารอ้างอิงการทำงานของ systemd มีคำเตือนเดียวกันสำหรับบริการที่มันเริ่ม
ให้การรีสตาร์ตอยู่ห่างจากความพร้อมใช้งานของอุโมงค์
การรีสตาร์ตรีเลย์ทำให้เซสชันที่ใช้งานอยู่หลุด และนั่นเป็นเหตุการณ์แยกจากการที่ VPN ล่ม จัดลำดับการเปลี่ยนแปลงให้อุโมงค์ยังขึ้นอยู่ขณะรีเลย์วนรอบ และเตือนทุกคนที่เซสชันยาวของตนพาดผ่านมัน
การย้อนกลับคือไฟล์ unit ก่อนหน้าบวกการรีสตาร์ตอีกครั้ง และไฟล์นั้นอยู่ที่เดิมจนกว่าค่าใหม่จะรอดผ่านวันทำงานหนึ่งวัน จากนั้นปิดวงด้วยคำขอที่ล้มเหลวแต่แรก เซสชัน SSH ใหม่หนึ่งเซสชันผ่านรีเลย์ การถ่ายโอนหนึ่งครั้งที่ยาวพอจะมีความหมาย และจำนวนตัวอธิบายไฟล์ที่กลับสู่ระดับว่าง