VPN สองสแตก: ไคลเอนต์เป็นผู้เลือกตระกูลที่อยู่ ไม่ใช่คุณ

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

การเลือกไม่ใช่คำสัญญาว่าจะครอบคลุม

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

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

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

ค้นหาตระกูลที่คำขอใช้จริง

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

dig +short A example.com
dig +short AAAA example.com
curl -4 -sS -o /dev/null -w '%{http_code}\n' https://example.com
curl -6 -sS -o /dev/null -w '%{http_code}\n' https://example.com

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

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

ตรวจสอบเส้นทางสำหรับตระกูลนั้น

สำหรับตระกูลที่ล้มเหลว ให้ถามเคอร์เนลว่าจะใช้เส้นทางใดและเปรียบเทียบกับที่อยู่ที่กำหนดค่าไว้ของอุโมงค์ บน Linux ip -6 route get สำหรับปลายทางจะแสดงอินเทอร์เฟซและต้นทางที่จะถูกเลือก

จากนั้นตรวจสอบอุโมงค์เอง WireGuard พีร์มีรายการ IP ที่อนุญาต และรายการสำหรับ 0.0.0.0/0 ไม่ได้บอกอะไรเกี่ยวกับ IPv6 ถ้ารายการของพีร์ไม่มีคำนำหน้า IPv6 ไคลเอนต์ก็ไม่มีเหตุผลจะส่งทราฟฟิก AAAA เข้าไปในอุโมงค์ และแพ็กเก็ตจะออกไปตามเส้นทางที่โฮสต์จะทำเป็นอย่างอื่น

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

อย่าปิดใช้งาน IPv6 เพื่อให้ภาพหน้าจอง่ายขึ้น

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

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

สิ่งที่ควรเขียนในตั๋ว

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

กฎการเลือกที่อยู่ของ RFC 6724 อธิบายว่าไคลเอนต์ให้ความสำคัญกับผู้สมัครรายนั้นเพราะอะไร และ RFC 8305 อธิบายพฤติกรรมการแข่งที่ซ่อนความหน่วงไว้ ไม่มีสิ่งใดจะกำหนดเส้นทางแพ็กเก็ตให้คุณ และนั่นคือส่วนที่อุโมงค์ต้องทำ