อุโมงค์เต็มรูปแบบของ WireGuard: AllowedIPs 0.0.0.0/0 ยังไม่พอ

การใส่ 0.0.0.0/0, ::/0 ลงใน AllowedIPs ของคู่ค้าเป็นขั้นตอนที่ทุกคนจำได้ และมันตัดสินเพียงว่าคู่ค้าได้รับอนุญาตให้ขนส่งทราฟฟิกใด คำนำหน้าเหล่านี้ไม่ได้สร้างเส้นทางใด ๆ ไม่ได้ส่งต่อสิ่งใดที่อีกฝั่ง และปล่อยให้ตัวแก้ไขชื่อของทุกแอปพลิเคชันอยู่ที่เดิมทุกประการ ต้องมีสี่สิ่งแยกกันเป็นจริงพร้อมกันเพื่อให้อุโมงค์เต็มรูปแบบเป็นอุโมงค์เต็มรูปแบบจริง ๆ และควรตรวจตามลำดับด้านล่าง เพราะการตรวจภายหลังไม่อาจช่วยการตรวจก่อนหน้าได้ การตรวจแต่ละข้อด้านล่างเป็นข้อเท็จจริงที่อ่านได้จากเครื่อง ไม่ใช่การตั้งค่าที่คุณหวังว่าจะถูกนำไปใช้

คำนำหน้าของคู่ค้าเลือกอะไร และไม่เลือกอะไร

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

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

กำหนดเส้นทางให้ไคลเอนต์ ไม่ใช่แค่รายการคู่ค้า

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

[Interface]
Address = 10.8.0.2/32
DNS = 10.8.0.1

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = vpn.example.net:51820

มีรายละเอียดสองอย่างที่รับงานนี้ ฟิลด์ Address เป็น คำนำหน้าโฮสต์เดียว ไม่ใช่ซับเน็ตที่ไคลเอนต์คิดว่าเป็นของตน และตัวจัดการคือผู้แปลง AllowedIPs ค่าเริ่มต้นให้เป็นเส้นทางเริ่มต้นจริง ยกไฟล์เดียวกันขึ้นด้วย ip link และ wg setconf จะไม่มีเส้นทางใดปรากฏเลย ซึ่งดูเหมือนอุโมงค์เสียแต่จริง ๆ เป็นอุโมงค์ที่ดีโดยข้ามขั้นตอนกำหนดเส้นทางไป คู่มือของ wg-quick อธิบายการกำหนดเส้นทางและ Table พฤติกรรมที่ตัวจัดการเหล่านี้เพิ่มเข้ามา

อ่านผลลัพธ์ไม่ใช่ไฟล์: ip route get 1.1.1.1 ควรระบุชื่ออินเทอร์เฟซของอุโมงค์ และ wg show ควรรายงานการจับมือล่าสุดพร้อมตัวนับการรับส่งที่เคลื่อนไหว การจับมือโดยไม่มีเส้นทางหมายความว่าตัวจัดการไม่เคยทำงาน และการแก้ไขโปรไฟล์อีกครั้งจะไม่แก้ไขสิ่งนั้น เริ่มอินเทอร์เฟซแบบเดียวกับที่ผู้ใช้จะเริ่ม มิฉะนั้นการทดสอบจะวัดเชลล์ของคุณแทนการปรับใช้

เก็บปลายทางไว้นอกอุโมงค์

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

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

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

การส่งต่อและเส้นทางขากลับบนเกตเวย์

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

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding
ip route get 1.1.1.1 from 10.8.0.2

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

DNS และสถานะความล้มเหลว ทดสอบแยกกัน

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

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

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