IPv6 ผ่านอุโมงค์ OpenVPN: การไล่ตรวจเราเตอร์ที่บ้าน

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

เริ่มจากจุดที่ไคลเอนต์อยู่

ดูไคลเอนต์ก่อนแตะเซิร์ฟเวอร์ ip -6 addr ควรแสดงที่อยู่อุโมงค์จากพูล และ ip -6 route ควรแสดงพรีฟิกซ์ที่ถูกดันซึ่งชี้ไปยังอุปกรณ์อุโมงค์ เมื่อมีที่อยู่แต่ไม่มีเส้นทาง แปลว่าการดันหายไปหรือไคลเอนต์เพิกเฉย เมื่อไม่มีทั้งสองอย่าง เซิร์ฟเวอร์ไม่ได้จัดสรรอะไรเลย

จากนั้นตรวจสอบว่าไคลเอนต์คิดอย่างไรกับโลกภายนอก เส้นทางเริ่มต้นผ่านอุโมงค์อ้างสิทธิ์ทราฟฟิก IPv6 ทั้งหมด ขณะที่เส้นทางสำหรับ 2000::/3 อ้างสิทธิ์เฉพาะยูนิแคสต์ทั่วโลก ทั้งสองอย่างอาจถูกต้อง และตอบคำถามต่างกันเกี่ยวกับการรั่ว

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

ตรวจสอบพูลที่เซิร์ฟเวอร์กำหนดเส้นทางได้จริง

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

พูลและการดันไปด้วยกัน server-ipv6 2001:db8:80:10::/64 จัดสรรที่อยู่ และ push "route-ipv6 2000::/3" บอกไคลเอนต์ว่าต้องส่งอะไรเข้าอุโมงค์ การดัน 2000::/3 ครอบคลุมยูนิแคสต์ทั่วโลกและกันช่วง link-local และ multicast ไว้นอกอุโมงค์

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

เปิดการส่งต่อสำหรับตระกูลที่สอง

การส่งต่อ IPv4 ไม่ได้หมายถึงการส่งต่อ IPv6 ตั้งค่า net.ipv6.conf.all.forwarding=1 และสะท้อนทุกอย่างที่นโยบาย FORWARD ของ IPv4 อนุญาตอยู่แล้ว บนเราเตอร์ที่เชน FORWARD ทิ้งแพ็กเก็ตโดยค่าเริ่มต้น ชุดกฎที่หายไปจะดูเหมือนอุโมงค์ที่ตายแล้วทุกประการ

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

ip6tables -A FORWARD -i br0 -o tun0 -j ACCEPT
ip6tables -A FORWARD -i tun0 -o br0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
ip6tables -A FORWARD -i tun0 -o wan0 -j ACCEPT

ผลข้างเคียงหนึ่งอย่างจับคนที่ลงเอยด้วยการโทษอุโมงค์ การเปิดการส่งต่อทำให้เคอร์เนลข้ามการกำหนดค่าที่อยู่ผ่าน Router Advertisement เว้นแต่จะบอกเป็นอย่างอื่น และเส้นทางเริ่มต้นที่เรียนมาแบบนั้นก็หายไปด้วย จะปักหมุดเส้นทางเริ่มต้นที่ชัดเจนบนอินเทอร์เฟซ WAN หรือตั้ง accept_ra เป็น 2 ตรงนั้นอย่างตั้งใจ หลังการเปลี่ยนแปลงใด ๆ ให้ยืนยันว่าเราเตอร์ยังมีเส้นทาง IPv6 ที่ใช้งานได้ออกไปก่อนทดสอบไคลเอนต์อีกครั้ง

ตอบสนองการค้นหาเพื่อนบ้านเมื่อต้นน้ำไม่กำหนดเส้นทาง

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

OpenVPN เปิดเผยที่อยู่ที่จัดสรรให้กับฮุก client-connect ดังนั้นรายการจึงสามารถตามพูลจริงแทนรายการที่ดูแลด้วยมือ ฮุกจะเพิ่ม ip -6 neigh add proxy $ifconfig_pool_remote_ip6 dev eth0 และฮุก client-disconnect ที่เข้าคู่กันจะลบออก หากไม่ลบ ตารางพร็อกซีจะล้าสมัยและไคลเอนต์ภายหลังอาจสืบทอดรายการสำหรับที่อยู่ที่ไม่เคยได้รับ ยืนยันสถานะด้วย ip -6 neigh show proxy

มองว่าพร็อกซีเป็นวิธีเลี่ยง เส้นทางแบบคงที่สำหรับ /64 ของอุโมงค์ที่ชี้ไปยังเราเตอร์นั้นทนต่อการเปลี่ยนไคลเอนต์และไม่ต้องใช้ฮุกเชลล์ที่มีสิทธิพิเศษเลย

ตามเส้นทางออกไปทีละฮอป

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

ระวัง MTU ของอุโมงค์ เพราะเราเตอร์ IPv6 ตามเส้นทางจะไม่แบ่งแพ็กเก็ตให้คุณ MTU ที่ใหญ่เกินไปจะปรากฏเป็นข้อผิดพลาด packet-too-big และ TLS ที่ค้างแทนที่จะล้มเหลวอย่างสะอาด ตั้งค่าให้ชัดเจนและทดสอบด้วยเพย์โหลดใกล้ขีดจำกัด