เริ่มไคลเอนต์ VPN ผ่าน SSH? ปักหมุดเส้นทางของคุณเองก่อน

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

บันทึกเส้นทางก่อนเริ่ม

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

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

ปักหมุดที่อยู่ในคอนฟิกูเรชันของไคลเอนต์เอง

เส้นทางที่เพิ่มด้วยมือจะหายไปเมื่อรีบูตและแข่งกับการอัปเดตตารางของไคลเอนต์เอง ดังนั้นใส่ข้อยกเว้นไว้ที่จุดที่ตารางถูกจัดการ ภายใต้ OpenVPN คำหลัก net_gateway จะถูกแปลงเป็นเกตเวย์ที่มีอยู่ก่อนอุโมงค์ ดังนั้น route 203.0.113.9 255.255.255.255 net_gateway เก็บที่อยู่หนึ่งรายการไว้ข้างนอกอย่างแม่นยำ WireGuard ต้องใช้วิธีอื่นเพราะ wg-quick จัดการเส้นทางเอง ตั้ง Table = off และเพิ่มข้อยกเว้นใน PostUp พร้อม PostDown ที่ตรงกันซึ่งลบมันออก ทั้งสองรูปแบบแสดงเจตนาเดียวกัน และทั้งสองจำกัดข้อยกเว้นไว้ที่ที่อยู่เดียวแทนที่จะทำให้อุโมงค์อ่อนแอลงสำหรับทุกสิ่ง

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

หรือเอาตารางหลักออกจากสมการ

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

ทั้งสองเป็นกลไกมากกว่าเส้นทางโฮสต์เดียว และทั้งสองคุ้มค่าเมื่อมีมากกว่าหนึ่งสิ่งบนเครื่องที่ต้องอยู่รอดผ่านอุโมงค์

สมมติว่าการปักหมุดอาจล้มเหลว

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

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

ตรวจสอบตามลำดับที่สำคัญ

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

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