ทราฟฟิก IPv6 ควรผ่าน VPN หรือตรงดี?
ตัดสินว่า ::/0 อยู่ในอุโมงค์หรือไม่ ด้วยเงื่อนไขสามข้อ: การรองรับของทางออก การเข้าถึงปลายทาง และเฉพาะเครือข่ายท้องถิ่น
เดือนที่แล้วมีสองคนขอผลลัพธ์ที่ตรงข้ามจากผม คนหนึ่งอยากให้ VPN ครอบคลุม IPv6 อีกคนอยากให้เครื่องพิมพ์ในออฟฟิศใช้งานได้ต่อไป เส้นทางเดียว ::/0 ไม่สามารถให้ทั้งสองอย่างได้ด้วยตัวเอง เส้นทางนั้นอยู่ในอุโมงค์หรือไม่ขึ้นอยู่กับเงื่อนไขสามข้อ และข้อแรกตัดมันออกสำหรับทางออกเชิงพาณิชย์ส่วนใหญ่ ถ้าทางออกไม่พา IPv6 การส่งเส้นทางเริ่มต้นไปที่นั่นจะซ่อนทราฟฟิกของคุณไว้ในอุโมงค์ที่ไม่มีที่ให้ส่ง
เงื่อนไขสามข้อเป็นตัวกำหนดคำตอบ
เส้นทางเริ่มต้นคือหนึ่งบรรทัด ::/0 และตรงกับปลายทาง IPv6 ใด ๆ ที่ไม่มีเส้นทางเฉพาะเจาะจงกว่า (RFC 4291) การติดตั้งมันง่าย การตัดสินว่าคุณควรทำหรือไม่ขึ้นอยู่กับเงื่อนไขสามข้อ
เงื่อนไขข้อหนึ่ง: ทางออกที่คุณเชื่อมต่อมี IPv6 ที่ใช้งานได้และพร้อมส่งต่อ เงื่อนไขข้อสอง: ไคลเอนต์ของคุณรักษาเส้นทางไปยังปลายทางของอุโมงค์ได้ ซึ่งโดยปกติอยู่ในช่วงที่คุณกำลังจะกำหนดเส้นทาง เงื่อนไขข้อสาม: คุณระบุปลายทาง IPv6 ในท้องถิ่นที่ต้องอยู่นอกอุโมงค์ได้
แต่ละเงื่อนไขล้มเหลวในแบบของตัวเอง นั่นคือเหตุผลที่การเดาต้องเสียเวลาทั้งเย็น เงื่อนไขข้อหนึ่งที่ล้มเหลวทำให้คุณได้ความเงียบและตารางเส้นทางที่ดูถูกต้อง เงื่อนไขข้อสองที่ล้มเหลวฆ่าการจับมือไม่กี่วินาทีหลังเริ่ม เงื่อนไขข้อสามที่ล้มเหลวทิ้งอุโมงค์ที่ใช้งานได้และเพื่อนร่วมงานที่ไม่พอใจไว้ที่เครื่องพิมพ์
| What you see | Decision |
|---|---|
| Exit answers IPv6 probes, no local IPv6 devices to protect | Route ::/0 into the tunnel |
| Exit answers IPv6 probes, printer or NAS reachable by a global address | Route ::/0, then give those prefixes a route of their own |
| Exit is IPv4-only inside the tunnel | Do not route ::/0; block IPv6 on the client |
Endpoint is reached over IPv6 and sits inside ::/0 | Install a host route for the endpoint first |
ทางออกพา IPv6 จริงหรือ
อินเทอร์เฟซอุโมงค์ที่มีที่อยู่ IPv6 ไม่ได้พิสูจน์อะไรเกี่ยวกับอีกฝั่ง โปรไฟล์เชิงพาณิชย์จำนวนมากมีเพียง IPv4 ภายใน เซิร์ฟเวอร์ให้ที่อยู่ v4 แก่คุณและทิ้งอย่างอื่นทั้งหมด ติดตั้งเส้นทางเริ่มต้นจาก AllowedIPs ทับลงไป แล้วเคอร์เนลจะส่ง IPv6 อย่างเต็มใจไปยังอินเทอร์เฟซที่คู่ของมันไม่เคยเห็น
ทดสอบจากไคลเอนต์ขณะอุโมงค์ทำงาน ping -6 -c 3 2001:4860:4860::8888 และ ip -6 route get 2001:4860:4860::8888 ตอบคำถามต่างกัน คือมีคำตอบกลับมาหรือไม่ และเคอร์เนลเลือกอุปกรณ์ใด เมื่อตัวที่สองเอ่ยชื่ออุโมงค์ของคุณและตัวแรกไม่คืนอะไร ปัญหาอยู่ที่ทางออกไม่ใช่เส้นทาง
ถ้าคุณดูแลทางออกเอง การทดสอบไคลเอนต์อาจผ่านและเส้นทางก็ยังอาจจบลงที่ทางตัน ยืนยันว่า net.ipv6.conf.all.forwarding=1 เปิดอยู่ที่เกตเวย์ และไฟร์วอลล์ของมันยอมรับแพ็กเก็ตที่ส่งต่อออกจากอุโมงค์ แพ็กเก็ตที่กำหนดเส้นทางถูกต้องไปยังทางออกที่ปฏิเสธการส่งต่อจะดูเหมือนบั๊กการกำหนดเส้นทางจากฝั่งไคลเอนต์ทุกประการ
ไคลเอนต์รักษาเส้นทางไปยังปลายทางได้หรือไม่
นี่คือกรณีที่จับผมได้บนแล็ปท็อปที่มีปลายทาง WireGuard เฉพาะ IPv6 ที่อยู่ปลายทางเป็นที่อยู่ทั่วโลกธรรมดา จึงตกอยู่ใน ::/0 กำหนดเส้นทางทั้งคำนำหน้าเข้าอินเทอร์เฟซ แล้วแพ็กเก็ตจับมือจะไล่ตามตัวเองเข้าไปในอุโมงค์ที่ยังพยายามสร้างอยู่ อุโมงค์ไม่เคยขึ้น และไม่มีอะไรในเอาต์พุตของไคลเอนต์บอกว่าทำไม
wg-quick จัดการเรื่องนี้บนลินุกซ์ มันได้เส้นทางจาก AllowedIPs ติดตั้งไว้ในตารางของตัวเอง และเพิ่มกฎนโยบายเพื่อให้ทราฟฟิกไปยังปลายทางถูกแก้ไขผ่านตารางหลักก่อน: กฎ suppress_prefixlength 0 ที่คุณพบใน ip -6 rule นั่นคือเหตุผลที่ wg-quick up สำเร็จในที่ที่ ip -6 route add default dev wg0 ที่เขียนด้วยมือตัดคุณออก
ตรวจสอบทั้งสองสถานะด้วย ip -6 route get <endpoint-v6> ก่อนและหลังยกอุโมงค์ ถ้าคำตอบเปลี่ยนไปยังอุปกรณ์อุโมงค์ของคุณ คุณได้ลบเส้นทางที่อุโมงค์ต้องการ เมื่อคุณเขียนเส้นทางเอง ให้เพิ่มเส้นทางโฮสต์ไปยังปลายทางผ่านเกตเวย์เดิม หรือเชื่อมต่อปลายทางผ่าน IPv4 และปล่อย IPv6 ให้เพย์โหลด
อะไรต้องอยู่นอกอุโมงค์
เส้นทางที่เฉพาะเจาะจงกว่าชนะเส้นทางเริ่มต้น คำนำหน้าบนลิงก์หรือช่วง ULA ที่มีเส้นทางของตัวเองจึงทำงานต่อไปโดยไม่ต้องใช้แรงเพิ่ม นี่คือเหตุผลเงียบ ๆ ที่การตั้งค่า IPv4 แบบอุโมงค์เต็มจำนวนจำนวนมากอยู่รอด: คำนำหน้า LAN เฉพาะเจาะจงกว่าเส้นทางเริ่มต้นและไม่เคยเข้าอุโมงค์
มันพังเมื่ออุปกรณ์ท้องถิ่นเข้าถึงได้ผ่านที่อยู่ทั่วโลก ซึ่งเป็นเรื่องปกติสำหรับเครื่องพิมพ์ที่เราเตอร์ตัวเดียวกันให้คำนำหน้าสาธารณะ NAS หรือโทรทัศน์ ที่อยู่เหล่านั้นตรงกับ ::/0 และไม่มีอะไรอื่น ดังนั้นมันจึงย้ายเข้าอุโมงค์พร้อมอย่างอื่นและหายไป
ตัดสินตามปลายทาง ไม่ใช่ตามโปรโตคอล ถ้าโฮสต์ท้องถิ่นสองหรือสามเครื่องสำคัญ ให้เส้นทางออกผ่านอินเทอร์เฟซกายภาพแก่คำนำหน้าของโฮสต์เหล่านั้น หรือเอาออกจากชุดที่เจรจาไว้ ถ้ารายการยังโตต่อไป คำตอบที่ซื่อตรงคือการแยกอุโมงค์สำหรับ IPv6 พร้อมรายการข้อยกเว้นเป็นลายลักษณ์อักษร ไม่ใช่เส้นทางเริ่มต้นที่คุณคอยแพตช์
ถ้าคำตอบคือไม่ ให้บล็อกมัน
การปล่อย IPv6 ไว้โดยไม่มีเส้นทางไม่เหมือนกับการปล่อยมันไว้เฉย ๆ โฮสต์ที่มีเส้นทางเริ่มต้น IPv6 ที่ใช้งานได้ยังคงใช้มันขณะอุโมงค์พา IPv4 ดังนั้น ทราฟฟิกออกไปข้าง VPN และทุกบริการที่ชอบ IPv6 เห็นที่อยู่จริงของคุณ นั่นคือการรั่วไหล ไม่ใช่อุโมงค์แยก
เลือกสักอย่างและจดไว้ว่าเลือกอันไหน กำหนดเส้นทางเริ่มต้นและยอมรับข้อแลกเปลี่ยนข้างต้น หรือปิด IPv6 ระหว่างที่อุโมงค์ทำงาน การละคำนำหน้าออกจาก AllowedIPs ไม่เพียงพอด้วยตัวเอง เพราะระบบปฏิบัติการเก็บเส้นทางเริ่มต้นของตัวเองไว้ บนลินุกซ์ เวอร์ชันตรง ๆ คือ sysctl -w net.ipv6.conf.all.disable_ipv6=1 ส่วนเวอร์ชันละเอียดกว่าทิ้ง IPv6 ไว้นอกอุโมงค์ด้วยกฎไฟร์วอลล์ ไคลเอนต์โทรศัพท์มีสวิตช์บล็อก IPv6 ที่ชัดเจนซึ่งทำงานเดียวกัน
ตรวจสอบเหมือนการรั่วไหล
ยกอุโมงค์ขึ้นและอ่านสถานะแทนที่จะเชื่อสวิตช์ ip -6 route show default ควรแสดงเส้นทางเริ่มต้นหนึ่งเส้น และ ip -6 route get สำหรับปลายทางนอก LAN ของคุณควรระบุอุปกรณ์อุโมงค์ ทำซ้ำทั้งสองอย่างหลังตัดการเชื่อมต่อ: เส้นทางเริ่มต้นที่อยู่รอดเกินอุโมงค์คือบั๊กที่คุณตามหา
จากนั้นทดสอบทิศทางตรงข้าม จากโฮสต์ในเครือข่ายท้องถิ่น เข้าถึงไคลเอนต์ที่ที่อยู่ IPv6 ท้องถิ่นของมัน ถ้าสิ่งนั้นหยุดทำงาน แสดงว่าเงื่อนไขข้อสามไม่เคยเป็นจริง ไม่ว่าตารางเส้นทางจะอ้างอะไรตอนนั้น
เขียนผลลัพธ์ไว้ที่ที่คนถัดไปจะพบ: คำนำหน้าใดยังคงเป็นท้องถิ่น ทำไม และไคลเอนต์ทำอะไรหลังตัดการเชื่อมต่อ สองบรรทัดใน runbook ช่วยวิศวกรคนถัดไปไม่ต้องค้นพบลูปปลายทางอีกครั้งตอนเที่ยงคืน