ไคลเอนต์ VPN บนเซิร์ฟเวอร์ LAN: ทำไมคำตอบจึงออกไปผิดทาง

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

คำตอบคือแพ็กเก็ตใหม่ ไม่ใช่การย้อนเส้นทาง

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

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

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

พิสูจน์ด้วยการดักจับและการค้นหา

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

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

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

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

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

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

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

ใช้ replace แทน add เพราะไคลเอนต์ที่เชื่อมต่อใหม่จะติดตั้งรายการของตัวเองแล้ว และ add ครั้งที่สองจะล้มเหลวด้วยข้อผิดพลาดว่าเส้นทางมีอยู่แล้วซึ่งอ่านเหมือนปัญหาสิทธิ์ บนโฮสต์ Windows ค่าเทียบเท่าคือ route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p โดย -p เก็บรายการไว้ข้ามการรีบูต เพราะไคลเอนต์อาจสร้างตารางใหม่เมื่ออุโมงค์กลับมา บนโฮสต์ Windows รุ่นใหม่ ค่าเทียบเท่าที่รองรับคือ New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore และคำสั่ง route เดิมยังคงเป็นรูปแบบเก่า

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

เก็บคำตอบไว้หลังการเชื่อมต่อใหม่

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

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

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