ให้ไคลเอนต์ OpenVPN หนึ่งรายเข้าถึงอีกรายผ่าน SSH โดยไม่เปิดพูล

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

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

client-to-client ย้ายแพ็กเก็ตไปที่ใด

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

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

เส้นทางที่แพ็กเก็ตของเพื่อนร่วมเครือข่ายเดินจริง

สมมติบริการ Linux Community OpenVPN 2.6 การประมวลผล TUN ในพื้นที่ผู้ใช้แทน DCO โทโพโลยีซับเน็ต tun0 และพูล 10.44.0.0/24 ที่มีไคลเอนต์ A อยู่ที่ 10.44.0.21 และไคลเอนต์ B อยู่ที่ 10.44.0.37 ด้วยโทโพโลยีซับเน็ต ที่อยู่และเน็ตมาสก์ที่ A ได้รับครอบคลุมพูลอยู่แล้ว A จึงส่งแพ็กเก็ตไปยังอุปกรณ์อุโมงค์โดยไม่ต้องมีเส้นทางที่ถูกดันเพิ่ม ตรวจสอบเส้นทางจริงบน A แทนที่จะสมมติ

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

กฎสองข้อบนเซิร์ฟเวอร์ ตามลำดับนี้

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

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i tun0 -o tun0 -s 10.44.0.21 -d 10.44.0.37 -p tcp --dport 22 -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i tun0 -o tun0 -j DROP

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

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

B ยังต้องอนุญาตอะไรอีก

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

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

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