SSH ServerAliveInterval บน VPN: ปลายทางใดส่งโพรบ?

คำแนะนำเรื่องการรักษาเซสชัน SSH ให้คงอยู่ส่วนใหญ่หยุดอยู่ที่ «เพิ่ม ServerAliveInterval 30» และละเลยส่วนที่มีประโยชน์ไป คำสำคัญคือตัวจับเวลาฝั่งไคลเอนต์ที่ทำงานเฉพาะเมื่อช่องสัญญาณเงียบ มีการนับโพรบที่ไม่ได้รับการตอบแทนการนับวินาที และอาศัยอยู่ในไฟล์ที่ค่าที่ตรงกันตัวแรกเป็นผู้ชนะ หากเข้าใจคุณสมบัติสามข้อนี้ผิด เซสชัน VPN ที่ปกติก็ยังหลุด ขณะที่เซสชันที่ตายแล้วกลับค้างอยู่

สองทิศทางเป็นของเดมอนคนละตัว

ServerAliveInterval ถูกอ่านโดยไคลเอนต์ ssh ของคุณ ส่วน ClientAliveInterval ถูกอ่านโดย sshd ที่อยู่อีกฝั่งและตรวจสอบในทิศทางกลับกัน คือจากเซิร์ฟเวอร์ไปยังไคลเอนต์ ทั้งสองไม่ใช่ชื่อเรียกแทนกันและไม่ทำงานร่วมกัน การตั้งค่าตัวหนึ่งจึงไม่มีผลต่อพฤติกรรมของอีกฝั่ง การสลับกันจึงเป็นสาเหตุปกติที่การแก้ไขดูเหมือนได้ผลบนโฮสต์หนึ่งแต่ไม่บนโฮสต์ถัดไป

ทั้งสองยอมรับค่าศูนย์ เมื่อเป็นศูนย์ไคลเอนต์จะไม่ส่งอะไรเลย และทางฝั่งเซิร์ฟเวอร์ ClientAliveCountMax ที่เป็นศูนย์จะปิดการตัดการเชื่อมต่อที่จะตามมาหลังการตรวจสอบที่ไม่ได้รับการตอบ

โพรบพิสูจน์อะไร และไม่พิสูจน์อะไร

เมื่อช่วงเวลาที่กำหนดผ่านไปโดยไม่มีข้อมูลจากเซิร์ฟเวอร์ ไคลเอนต์จะส่งคำขอเล็ก ๆ ผ่านช่องทางที่เข้ารหัสอยู่แล้วและรอคำตอบ ServerAliveCountMax กำหนดว่ามีกี่ครั้งที่ยังไม่ได้รับคำตอบได้ก่อนที่เซสชันจะถูกตัด เมื่อช่วงเวลา 60 และจำนวน 3 ไคลเอนต์จะยอมแพ้หลังความเงียบราวสามนาที และตัวเลขนั้นเป็นคุณสมบัติของการตั้งค่าของคุณ ไม่ใช่มาตรฐานเครือข่าย หากปล่อยช่วงเวลาไว้ที่ค่าเริ่มต้น 0 จะไม่มีการส่งโพรบเลย ซึ่งเป็นเหตุผลที่ไคลเอนต์ทั่วไปสามารถนั่งอยู่บนการเชื่อมต่อที่ตายแล้วได้ไม่จำกัด

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

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

ลำดับเป็นตัวตัดสินว่าค่าใดอยู่รอด

OpenSSH ใช้ค่าแรกที่ได้มาสำหรับแต่ละพารามิเตอร์ บล็อก Host ที่เจาะจงจึงต้องอยู่ก่อนบล็อกที่กว้างกว่าซึ่งตรงกันด้วย วางค่าเริ่มต้นที่มีไวลด์การ์ดไว้ท้ายไฟล์ ไม่ใช่ตอนต้น และจำไว้ว่าบล็อก Match ที่อยู่ถัดลงไปไม่สามารถเขียนทับค่าที่ตั้งไว้แล้วได้ เอกสารอ้างอิงการตั้งค่าไคลเอนต์ OpenSSH ระบุกฎของค่าแรกไว้โดยตรง และควรอ่านสักครั้งก่อนจัดเรียงการตั้งค่าที่ใช้ร่วมกันใหม่

ตัวเลือกบนบรรทัดคำสั่งชนะไฟล์ ทำให้การทดลองชั่วคราวมีต้นทุนต่ำ:

ssh -o ServerAliveInterval=15 -o ServerAliveCountMax=4 office-shell

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

ssh -G office-shell | grep -i alive

คีปอะไลฟ์ทำอะไรผ่านอุโมงค์

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

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

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

การยืนยันการตั้งค่าตั้งแต่ต้นจนจบ

บนเซิร์ฟเวอร์ ให้แสดงการตั้งค่าของเดมอนที่มีผลบังคับใช้ แทนที่จะอ่านไฟล์แล้วเดาว่า include ใดชนะ:

sshd -T | grep -i clientalive

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

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