ทำไมเซิร์ฟเวอร์หลังไคลเอนต์ VPN จึงตอบกลับผ่านอุโมงค์

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

คำตอบถูกกำหนดเส้นทาง ไม่ใช่ถูกจำ

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

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

การกรองเส้นทางย้อนกลับแบบเข้มงวดอาจทิ้งแพ็กเก็ตขาเข้าก่อนที่แดมอนจะอ่านด้วยซ้ำ ตรวจสอบตัวนับนั้นก่อน เพราะการทิ้งจากตัวกรองกับข้อผิดพลาดในการกำหนดเส้นทางดูเหมือนกันจากภายนอก

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

คำสั่งแรกแสดงว่าเส้นทางเริ่มต้นใดชนะอยู่ในขณะนี้ คำสั่งที่สองรายงานว่าการกรองแบบเข้มงวดใช้ทั่วระบบหรือแยกตามอินเทอร์เฟซ และคำสั่งที่สามแสดงกฎใด ๆ ในเชนส่งต่อที่อาจเกี่ยวข้อง

สามวิธีรักษาเส้นทางกลับ

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

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

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

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

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

เมื่อกล่องยังกำหนดเส้นทางให้ LAN ด้วย

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

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

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

สามการตรวจที่แยกสาเหตุ

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

แก้ปัญหาการกำหนดเส้นทางก่อน แล้วจึงดูชื่อ การผสมทั้งสองอย่างคือวิธีที่เซิร์ฟเวอร์ที่ทำงานอยู่ถูกตำหนิเรื่องตัวแก้ชื่อที่เสีย

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