ไคลเอนต์ WireGuard ไม่สามารถเข้าถึงไคลเอนต์ OpenVPN ได้หรือ?

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

อาการขาดชิ้นส่วนทีละอย่าง

ดีไซน์นี้ใช้พูล WireGuard 10.71.0.0/24 บน wg1 และพูล OpenVPN 10.72.0.0/24 บน tun1 โดยทั้งคู่สิ้นสุดที่เกตเวย์ตัวเดียว คำขอที่ทดสอบวิ่งจาก 10.71.0.5 ไปยัง HTTPS บน 10.72.0.30 ทุกขั้นตอนด้านล่างเกี่ยวกับโฟลว์เดียวนี้ แต่ละการตรวจมีลายเซ็นความล้มเหลวต่างกันแม้ผู้ใช้จะรู้สึกเหมือนกัน และปกติจะมีเพียงหนึ่งในสามอย่างที่ขาดไปในแต่ละครั้ง

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

ขยายความครอบคลุมปลายทางของสโปก

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

AllowedIPs = 10.71.0.0/24, 10.72.0.0/24

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

รักษาความเป็นเจ้าของต้นทางไว้ที่เกตเวย์

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

AllowedIPs = 10.71.0.5/32

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

ให้ฝั่ง OpenVPN มีเส้นทางขากลับ

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

push "route 10.71.0.0 255.255.255.0"

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

อนุญาตเฉพาะบริการเดียวที่คุณตั้งใจจะอนุญาต

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

sudo ufw --dry-run route allow in on wg1 out on tun1 proto tcp from 10.71.0.5 to 10.72.0.30 port 443

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

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