อุโมงค์เต็มรูปแบบฆ่าเซสชัน SSH ของคุณ: ปักหมุดเส้นทางขากลับ

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

สิ่งที่ redirect-gateway ติดตั้งจริง ๆ

ในรูปแบบ def1 นั้น redirect-gateway จะเพิ่ม 0.0.0.0/1 และ 128.0.0.0/1 แทนการเขียนทับเส้นทางเริ่มต้น สองครึ่งนี้ครอบคลุมพื้นที่ที่อยู่ทั้งหมด ขณะที่ทั้งคู่ยังเป็นคำนำหน้าที่ยาวกว่า 0.0.0.0/0 ดังนั้นปลายทางใดที่ไม่มีรายการตรงกันที่เฉพาะเจาะจงกว่าก็จะเข้าสู่อุโมงค์ในตอนนี้ นั่นคือกลไกที่ต้องจดจำ เพราะทุกวิธีแก้ด้านล่างทำงานโดยการติดตั้งรายการตรงกันที่เฉพาะเจาะจงกว่า

ที่อยู่ผู้ดูแลระบบของคุณคือหนึ่งในปลายทางเหล่านั้น

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

ip route show table main | head -n 20
ip route get 198.51.100.23

หาแอดเดรสต้นทางและเส้นทางก่อนมีอุโมงค์

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

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

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

ปักหมุดเส้นทางโฮสต์ที่เหนือกว่าเส้นทางครึ่งเริ่มต้น

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

ip route add 198.51.100.23/32 via 203.0.113.1 dev eth0

ตรวจสอบด้วยการค้นหาเส้นทาง ไม่ใช่ด้วยการดูตาราง คำตอบต้องระบุ eth0 และเกตเวย์ ไม่ใช่ tun0

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

ทำให้อยู่รอดเมื่อเชื่อมต่อใหม่

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

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

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

เมื่อเส้นทางที่ปักหมุดไว้ยังไม่พอ

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

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

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