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

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

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

ทำไมคำตอบจึงออกผิดประตู

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

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

ความผิดพลาดเรื่องคำนำหน้าหนึ่งอย่างควรตัดออกตั้งแต่เนิ่น ๆ คำสั่ง ip route add -net 0.0.0.0 gw 10.8.0.1 dev tun0 ที่ไม่มีความยาวจะตรงกับที่อยู่เดี่ยว 0.0.0.0 ไม่ใช่กับอินเทอร์เน็ต ต้องเป็น 0.0.0.0/0 และถ้าการใช้เส้นทางเริ่มต้นทำให้การขนส่งของอุโมงค์เองเสียหาย ให้เพิ่มปลายทางเป็นเส้นทางโฮสต์ผ่านอินเทอร์เฟซทางกายภาพ โดยใช้ที่อยู่จริงของผู้ให้บริการ

ปักหมุดที่อยู่ไคลเอนต์ SSH เพื่อซ่อมทันที

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

curl -s https://ifconfig.co
ip route

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

sudo ip route add 80.128.240.55 via 192.168.178.1

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

อย่าให้ไคลเอนต์ใช้เส้นทางเริ่มต้น

ตัวเลือกที่สะอาดกว่าคือไม่ให้อุโมงค์แทนที่เส้นทางเริ่มต้นเลย route-nopull เมื่อใช้กับ --client หรือ --pull จะยอมรับตัวเลือกที่ถูกส่งมา ยกเว้นเส้นทาง block-outside-dns และตัวเลือกแบบ DHCP เช่นเซิร์ฟเวอร์ DNS คุณจึงเพิ่มเฉพาะคำนำหน้าที่ต้องการ เครื่องมือที่แคบกว่าคือตัวกรองการดึง ซึ่งทิ้งคำสั่งที่มีปัญหาหนึ่งรายการและเก็บส่วนที่เหลือไว้

route-nopull
pull-filter ignore "redirect-gateway"

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

แยกเส้นทางขากลับตามต้นทางหรือตามการเชื่อมต่อ

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

ip rule add from 192.168.1.11 table 128
ip route add table 128 to 192.168.1.0/24 dev eth0
ip route add table 128 default via 192.168.1.1

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

iptables -t mangle -A PREROUTING -i eth0 -m conntrack --ctstate NEW -j CONNMARK --set-mark 1234
iptables -t mangle -A OUTPUT -m connmark --mark 1234 -j MARK --set-mark 4321
ip route add default via 192.168.1.1 dev eth0 table 3412
ip rule add fwmark 4321 table 3412

แยกเครื่องหมายการเชื่อมต่อ เครื่องหมายไฟร์วอลล์ และหมายเลขตารางออกจากกันขณะทดสอบ การใช้หมายเลขเดียวสำหรับสองบทบาทจะสร้างกฎที่ดูถูกต้องและไปโดนแพ็กเก็ตผิด รายการเริ่มต้นของตารางยังต้องมี via พร้อมเกตเวย์ LAN บนลิงก์ Ethernet ทั่วไป การใช้ dev eth0 เปล่า ๆ ได้ผลเฉพาะเมื่ออินเทอร์เฟซเป็นแบบจุดต่อจุดหรือฮ็อปถัดไปถูกแก้ด้วยวิธีอื่น โฮสต์ Jessie ที่รายงานบังเอิญอยู่บนลิงก์ที่รูปแบบเปล่าได้ผล ซึ่งไม่ใช่กฎการกระจายที่ควรลอก

ตรวจสอบโดยไม่ล็อกตัวเองออกไปข้างนอก

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

ip route get 80.128.240.55

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

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