pfSense OpenVPN: เข้าถึงเครือข่ายที่อยู่หลังเราเตอร์อีกตัว

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

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

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

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

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

ให้คำนำหน้าแก่ไคลเอนต์ ไม่ใช่การเดา

บนเซิร์ฟเวอร์ pfSense SSL/TLS ที่มีเครือข่ายอุโมงค์ IPv4 ใหญ่กว่า /30 ฟิลด์ IPv4 Local network(s) จะกระจายเส้นทางให้ไคลเอนต์เมื่อเชื่อมต่อ ให้เพิ่มคำนำหน้าชั้นล่างตรงนั้นแทนการหวังให้ไคลเอนต์คิดขึ้นมาเอง จากนั้นอ่านตารางจริงของไคลเอนต์หลังเชื่อมต่อ เพราะโปรไฟล์ที่มี route-nopull หรือตัวกรองเส้นทางอาจเพิกเฉยต่อสิ่งที่เซิร์ฟเวอร์ส่งมา เซิร์ฟเวอร์อาจถูกต้องสมบูรณ์ในขณะที่ไคลเอนต์ไม่ได้ติดตั้งอะไรเลย

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

ชี้ pfSense ไปที่เราเตอร์ภายใน

เส้นทางแบบคงที่ใน pfSense ต้องมีเกตเวย์ที่กำหนดไว้และเข้าถึงได้ และอินเทอร์เฟซที่เลือกสำหรับเกตเวย์นั้นต้องเป็นตัวที่เข้าถึงได้จริง ตามที่คู่มือเส้นทางแบบคงที่ของ Netgate อธิบาย ในเลย์เอาต์ตัวอย่าง ลิงก์ทรานซิตคือ 192.168.77.1 บนไฟร์วอลล์ และ 192.168.77.2 บนเราเตอร์ภายใน โดยมีเครือข่ายบริการอยู่ที่ 172.16.30.0/25 อยู่ข้างหลัง จากนั้นเส้นทางจะระบุคำนำหน้าและฮอปถัดไป ไม่ใช่ที่อยู่ของบริการ การใช้ที่อยู่จากเครือข่ายระยะไกลเป็นเกตเวย์เป็นวิธีทั่วไปในการสร้างเส้นทางที่ดูถูกต้องแต่ไม่ส่งต่อไปที่ใดเลย

การตั้งชื่อให้อินเทอร์เฟซไม่ได้อธิบายเครือข่ายที่อยู่เบื้องหลัง เส้นทางแบบคงที่คือคำอธิบายนั้น

ฝั่งไกลต้องรู้จักพูล

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

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

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

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