ไคลเอนต์ปลายน้ำหลัง VPN ต้นน้ำ: เส้นทางหรือ NAT?

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

ตัดสินใจเรื่องโมเดลการส่งกลับก่อนจะแตะการกำหนดเส้นทาง

ในคำแนะนำนี้ ไคลเอนต์ปลายน้ำใช้ 10.90.0.0/24 ที่อยู่ทันเนลต้นน้ำที่กำหนดให้เกตเวย์คือ 10.80.0.6 และทรัพยากรปลายทางที่อนุมัติคือ 172.20.0.30 มีสองโมเดลที่เข้ากับรูปแบบนี้ คือคงต้นทางปลายน้ำไว้แล้วให้ฝั่งไกลกำหนดเส้นทางให้ หรือ แปลต้นทางเป็นที่อยู่ทันเนลของเกตเวย์เอง ทุกอย่างหลังจากนี้เป็นกลไก และตัวการตัดสินใจต้องอาศัยเจ้าของบริการ แถวหนึ่งข้างบนคือข้อตกลงเส้นทางกับฝั่งไกล อีกแถวคือการเปลี่ยนนโยบายภายในที่คุณทำได้เอง การสับสนระหว่างสองสิ่งนี้คือสิ่งที่เปลี่ยนงานสิบนาทีให้เป็นการเจรจา

preserved:  10.90.0.23 -> 172.20.0.30
translated: 10.80.0.6  -> 172.20.0.30

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

การรักษาต้นทางด้วยเส้นทาง

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

ถ้าคำตอบคือใช่ การกำหนดค่าภายในจะเล็กน้อย คือเปิดการส่งต่อ ตั้ง allowed-ips ของ peer WireGuard ให้ครอบคลุมช่วงปลายน้ำ และนโยบายไฟร์วอลล์ที่อนุญาตให้ข้ามผ่านได้ทั้งสองทิศทาง

การแปลต้นทางอย่างตั้งใจ

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

IPv6 ต้องมีการออกแบบของตัวเอง การคัดลอกบรรทัด masquerade ของ IPv4 ไม่ใช่สถาปัตยกรรม ทดสอบเส้นทางที่แปลแล้วด้วยการเชื่อมต่อใหม่ ไม่ใช่ที่แคชไว้

เส้นทางข้อมูลภายในยังต้องทำงาน

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

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

ต้นทางเดียวหมายถึงตัวตนเซสชันเดียว

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

เขียนการยืนยันนั้นลงใน runbook ข้าง ๆ กฎ เพราะผู้ตรวจทานคนถัดไปจะถามว่าการออกแบบได้รับอนุมัติหรือเพียงแค่สะดวก

กำหนดสถานะการตัดการเชื่อมต่อ แล้วทดสอบคำขอสามกรณี

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

บันทึกการย้อนกลับในหนึ่งบรรทัดต่อกฎ เพื่อให้สามารถยกเลิกการเปลี่ยนแปลงได้โดยไม่ต้องสร้างเจตนาขึ้นใหม่