วิธีทดสอบ IPv6 ผ่าน VPN ด้วยทรัพยากรของคุณเอง

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

ขั้นตอนที่ 1: ระบุว่าคุณกำลังทดสอบเส้นทาง IPv6 ใด

ระบุเป็นประโยคเดียว คำขอไปยังที่อยู่ IPv6 ของเซิร์ฟเวอร์อุโมงค์เองทดสอบอุโมงค์ คำขอไปยังโฮสต์ที่อยู่เลยทางออกไปทดสอบการออก IPv6 ของทางออก คำขอไปยังที่อยู่ IPv6 ส่วนตัวทดสอบเส้นทางภายใน

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

ขั้นตอนที่ 2: ยืนยันว่าโฮสต์เลือกเส้นทางนั้น

ip -6 route get 2001:db8:1::10 พิมพ์เส้นทาง ที่อยู่ต้นทาง และอินเทอร์เฟซที่เคอร์เนลจะใช้ และส่วนที่เหลือของการทดสอบขึ้นอยู่กับข้อเท็จจริงนี้

การมีอินเทอร์เฟซไม่เหมือนกับการถูกเลือก โฮสต์แบบสองสแตกมีตารางลำดับความสำคัญ และ /etc/gai.conf บน Linux เปลี่ยนได้ว่าครอบครัวใดจะชนะสำหรับชื่อที่แก้ได้ทั้งสองแบบ

ขั้นตอนที่ 3: ใช้ปลายทางและชื่อที่ชอบด้วยกฎหมาย

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

รันคำขอในรูปแบบที่แสดงที่อยู่ที่ใช้: curl -6 -sS -o /dev/null -w '%{remote_ip} %{http_code}\n' https://test6.example.net/ ตัวเลือก -6 บังคับครอบครัว และนี่คือวิธีที่คุณแยก IPv6 ใช้ไม่ได้ ออกจาก IPv6 ไม่ถูกเลือก

สำหรับการตรวจการเข้าถึงล้วน ๆ ที่อนุญาต ICMPv6 ping -6 -c 3 2001:db8:1::10 ก็เพียงพอ มันพิสูจน์เส้นทางและไม่มีอะไรเหนือกว่านั้น

ขั้นตอนที่ 4: เทียบเคียงทั้งสองปลาย

เมื่อคุณเข้าถึงได้ทั้งสองปลาย ให้รัน tcpdump -ni any ip6 and host 2001:db8:1::10 บนไคลเอนต์และสิ่งที่เทียบเท่าบนทรัพยากร พร้อมการประทับเวลา และยืนยันว่ากระแสเดียวกันปรากฏทั้งสองฝั่ง นี่คือสิ่งที่เปลี่ยนผลลัพธ์ที่น่าเชื่อให้เป็นหลักฐาน เพราะมุมมองของไคลเอนต์อย่างเดียวแยกคำตอบจากทรัพยากรออกจากคำตอบจากสิ่งใดสิ่งหนึ่งตรงกลางไม่ได้ รักษาการดักจับให้แคบที่ปลายทางเดียว เพื่อให้ผลลัพธ์อ่านได้และไม่มีเซสชันที่ไม่เกี่ยวข้องของใครไปอยู่ในไฟล์

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

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

ขั้นตอนที่ 5: จดว่าการทดสอบไม่ได้พิสูจน์อะไร

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

บันทึกที่คุ้มค่าแก่การเก็บนั้นสั้น: ปลายทาง ชื่อ ที่อยู่ต้นทางที่โฮสต์เลือก ที่อยู่ปลายทางไกลที่สังเกตได้ และเวลา RFC 7359 อภิปรายวิธีทดสอบว่าเส้นทาง IPv6 ที่เกี่ยวข้องใช้งานได้จริง และนี่คือมาตรฐานที่คู่มือนี้เข้าใกล้ด้วยเครื่องมือง่ายกว่า หากข้อสรุปต้องอาศัยเครื่องตรวจสาธารณะจึงจะเป็นจริง การทดสอบก็ไม่เฉพาะเจาะจงพอ