ส่งเฉพาะพอร์ต 25 เข้าทันเนล ไม่ใช่โฮสต์

สี่สิ่งต้องสอดคล้องกันก่อนที่โฮสต์ Linux จะส่งเฉพาะ SMTP ของตัวเองออกผ่านทันเนล ได้แก่ เส้นทางในตารางเฉพาะ กฎนโยบายที่เลือกทราฟฟิก ที่อยู่ต้นทางที่ peer จะยอมรับ และเส้นทางขากลับที่ทนต่อความไม่สมมาตร แต่ละอย่างเป็นการกำหนดค่าที่แยกจากกันพร้อมโหมดล้มเหลวของตัวเอง ลำดับด้านล่างคือลำดับที่ทำให้ความล้มเหลวชี้ไปยังส่วนที่ผิดจริง ๆ นี่คืองานกำหนดเส้นทางเฉพาะพอร์ต ไม่ใช่คำขอเส้นทางเริ่มต้นของ VPN

กฎพอร์ตไม่ใช่เส้นทางเริ่มต้น

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

การตั้งค่า wg-quick สองอย่างเป็นข้อกำหนดเบื้องต้น ไม่ใช่ส่วนหนึ่งของนโยบาย AllowedIPs = 0.0.0.0/0 อนุญาตให้ peer พาเป้าหมาย IPv4 ใดก็ได้ และ Table = off หยุด wg-quick ไม่ให้ติดตั้งเส้นทางเริ่มต้นของตัวเองสำหรับคำนำหน้านั้น อย่าผสมคำแนะนำเหล่านี้กับตัวจัดการที่ใช้นโยบายเส้นทางของตัวเอง เพราะทั้งสองจะไม่เห็นด้วยว่าใครเป็นเจ้าของตารางหลัก

เขียนเส้นทาง ตัวเลือก และตัวป้องกัน

เลือกหมายเลขตารางและคู่ลำดับความสำคัญที่ไม่มีอย่างอื่นใช้ แล้วจึงใช้เส้นทาง ตัวเลือก และตัวป้องกันตามลำดับนั้น ตัวเลขด้านล่างเป็นตัวอย่าง ไม่ใช่ค่าที่สงวนไว้

ip -4 route add default dev wg0 src 10.77.0.2 table 51825
ip -4 rule add priority 10000 iif lo ipproto tcp dport 25 lookup 51825
ip -4 rule add priority 10001 iif lo ipproto tcp dport 25 unreachable

iif lo จำกัดกฎให้กับทราฟฟิกที่เกิดในเครื่อง และ ipproto tcp dport 25 ระบุทิศทางของการเชื่อมต่อ เอกสารอ้างอิง ip-rule อธิบายตัวเลือกทั้งสอง มีอยู่ในเคอร์เนลและรุ่น iproute2 ปัจจุบัน และในระบบที่เก่ากว่าจะถูกปฏิเสธทันที ซึ่งเป็นความล้มเหลวที่ชัดเจนกว่ากฎที่โหลดแล้วไม่ตรงกับอะไรเลย

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

ที่อยู่ต้นทางต้องสอดคล้อง

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

ที่เกตเวย์ peer ของไคลเอนต์ต้องอนุญาตต้นทางที่ได้รับจริง นั่นคือ 10.77.0.2/32 ไม่ใช่คำนำหน้าเป้าหมายแบบกว้าง การคัดลอก 0.0.0.0/0 ของไคลเอนต์ไปยังทุก peer ของเกตเวย์ทำให้สับสนว่า peer ใดเป็นเจ้าของทราฟฟิกใด เกตเวย์ยังต้องมีการส่งต่อ นโยบายไฟร์วอลล์ที่อนุญาตการไหล และเส้นทางขากลับ รวมถึงการแปลงขาออกเมื่อต้นน้ำไม่สามารถกำหนดเส้นทางที่อยู่ทันเนลส่วนตัวได้

ตรวจเส้นทางขากลับ แล้วจึงตรวจความต่อเนื่อง

อ่านผลการค้นหาก่อนที่จะเชื่อถือสิ่งใด เพราะมันแสดงว่าทิศทางแต่ละทางได้ตารางใดและต้นทางใด ปลายทางหนึ่งบนพอร์ต 25 และปลายทางเดียวกันบนพอร์ต 443 ก็เพียงพอ

ip -4 route get 198.51.100.25 ipproto tcp dport 25
ip -4 route get 198.51.100.25 ipproto tcp dport 443

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

เมื่ออนุญาตการกำหนดเส้นทางแบบไม่สมมาตร โหมดหลวมที่จำกัดเฉพาะอินเทอร์เฟซผ่าน net.ipv4.conf.wg0.rp_filter=2 อาจเหมาะสม และควรตรวจสอบค่าสูงสุดที่มีผลของ all และอินเทอร์เฟซก่อน อย่าปิดการตรวจสอบทั้งระบบเป็นทางลัด จากนั้นมอบตาราง ลำดับความสำคัญ และตัวป้องกันให้ผู้ที่เป็นเจ้าของการกำหนดค่า และเปิดการเชื่อมต่อใหม่หลังเชื่อมต่อใหม่เพื่อยืนยันว่าการเลือกยังคงอยู่ โปรดจำไว้ว่าการตอบกลับจากตัวรับฟัง SMTP ในเครื่องมีพอร์ตต้นทาง 25 ไม่ใช่พอร์ตปลายทาง 25 ซึ่งเป็นคำถามนโยบายแยกต่างหาก