SSH หลุดบน VPN ทุกนาที? ไม่ใช่ keepalive

SSH เชื่อมต่อได้ ทำงานราวหนึ่งนาที แล้วค้างที่ช่วงเวลาใกล้เดิมทุกครั้ง คำอธิบายทั่วไปคือ idle timeout ผู้คนจึงลด MTU และตั้ง keepalive ฝั่งไคลเอนต์ ลิงก์ WireGuard ที่ผมทำงานด้วยเคยผ่านทั้งหมดนั้นมาแล้ว: MTU อุโมงค์ที่เล็กลง การตั้งค่า client-alive และ keepalive ของอุโมงค์ที่กำหนดไว้ การหลุดยังคงดำเนินต่อไปโดยไม่เปลี่ยนแปลง สาเหตุกลายเป็นเส้นทาง LAN ที่ไม่สมมาตร และรูปแบบนี้ควรค่าแก่การจดจำเพราะมันเอาชนะการแก้ไขใดๆ ที่อิงตัวจับเวลา

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

ความเชื่อผิด: keepalive แก้การหลุดแบบเงียบ

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

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

สัญญาณคือความสม่ำเสมอพร้อมกับเซสชันที่ยังใช้งานได้ภายในช่วงเวลานั้น idle timeout เกิดเมื่อไม่มีอะไรเกิดขึ้น ส่วนอันนี้เกิดขณะที่คุณพิมพ์

เกตเวย์เพิ่มเติมทำอะไรจริงๆ

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

ที่อยู่ด้านล่างสะท้อนการจัดวางนั้น

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

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

ไม่มีสิ่งใดในนี้ปรากฏในการกำหนดค่าไคลเอนต์ การค้นหาจึงมักเริ่มในไฟล์ผิด

เลือกเส้นทางเดียวอย่างตั้งใจ

สำหรับการจัดวางข้างต้น การเราเตอร์ซับเน็ตระยะไกลตรงไปยังเกตเวย์ VPN จะขจัดครึ่งการเชื่อมต่อ:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

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

ถ้าไฟร์วอลล์มีไว้กำกับทราฟฟิกระหว่างระบบเหล่านั้น การเราเตอร์อ้อมมันคือการออกแบบที่ผิด ให้ทั้งสองทิศทางข้ามพรมแดนแทน และกำหนดเส้นทางแต่ละฝั่งให้เส้นทางขากลับตรงกัน เป้าหมายคือเส้นทางเดียวอย่างตั้งใจ ไม่ใช่การตรวจสอบสถานะที่น้อยลง

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

ทดสอบจากทั้งสองปลาย

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

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

เมื่อใดความไม่สมมาตรเป็นเรื่องปกติ

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

คำตอบที่ยั่งยืนระบุชื่อเส้นทางสองเส้นทาง อุปกรณ์ที่ต้องมองเห็นทั้งสอง และเส้นทางที่ทำให้เป็นไปได้ ถ้าคุณระบุอุปกรณ์ไม่ได้ คุณยังไม่พบสาเหตุ