หยุดไม่ให้ไคลเอนต์ VPN เข้าถึงกันในอุโมงค์

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

เส้นทางไปยังบริการร่วมไม่ใช่การอนุญาตระหว่างเพียร์

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

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

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

ค้นหาว่าใครส่งต่อแพ็กเก็ตของเพียร์จริง ๆ

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

WireGuard อยู่ในกลุ่มแรก ไม่มีสวิตช์ระหว่างเพียร์ แพ็กเก็ตจาก 10.8.0.4 ไป 10.8.0.5 จึงมาถึงบน wg0 ชนฮุกส่งต่อ และถูกกำหนดเส้นทางออกจาก wg0 อีกครั้งเมื่อ AllowedIPs ครอบทั้งสองที่อยู่ OpenVPN คือกลุ่มที่สองเมื่อตั้ง client-to-client ในการตั้งค่าเซิร์ฟเวอร์ เพราะไดเรกทีฟนั้นส่งแพ็กเก็ตระหว่างเซสชันใน user space ตรวจสอบการตั้งค่าที่โหลดไว้สำหรับไดเรกทีฟนั้นก่อนเขียนอะไร กฎเคอร์เนลที่ไม่เคยเห็นทราฟฟิกแยกจากกฎที่ทำงานไม่ได้ และนั่นคือวิธีที่การติดตั้งจบลงโดยไม่มีการแยกเลย

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

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

ให้ทุกที่อยู่มีตัวตนที่เพิกถอนได้เอง

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

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

วางการปฏิเสธตรงที่แพ็กเก็ตข้ามอุโมงค์

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

ด้วย nftables คู่นี้เข้าไปในตาราง inet filter ที่มีอยู่ อนุญาตก่อนและทิ้งทีหลัง การจับคู่ทั้งสองตรึงคู่อินเทอร์เฟซรวมทั้งที่อยู่

nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.2.0/24 accept
nft add rule inet filter forward iifname "wg0" oifname "wg0" ip saddr 10.8.0.0/24 ip daddr 10.8.0.0/24 drop

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

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

พิสูจน์การปฏิเสธจากไคลเอนต์ ไม่ใช่จากเซิร์ฟเวอร์

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

จากไคลเอนต์ที่ได้รับอนุญาต ยืนยันว่าบริการตอบบนพอร์ตของมัน จากไคลเอนต์เดียวกัน ลองที่อยู่ของเพียร์และคาดว่าจะถูกทิ้งอย่างเงียบ ๆ ไม่ใช่ถูกปฏิเสธ

ping -c 3 -W 2 10.8.0.5
nc -z -w 2 10.8.0.5 22
nft list chain inet filter forward
iptables -vnL FORWARD
ping -6 -c 3 -W 2 fd00:8::5

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