NAT ของ LAN ผ่าน tun0 บนเกตเวย์ VPN OpenBSD

วิศวกรสองคนที่มีเกตเวย์ OpenBSD เดียวกันมักจะให้ชุดกฎที่ต่างกันในการเข้าถึงเครือข่ายระยะไกล และทั้งสองแบบก็ป้องกันได้ การเลือกระหว่างการแปลต้นทางกับเส้นทางย้อนกลับไม่ใช่คำถามเรื่องไวยากรณ์เลย มันขึ้นอยู่กับว่าอีกฝั่งรู้เรื่อง 192.168.88.0/24 อยู่แล้วมากแค่ไหน และคุณต้องเก็บอะไรไว้ในบันทึก ถ้าตรงนี้ผิด บรรทัด nat-to จะดูถูกต้องสมบูรณ์ขณะที่คำตอบหายไปในเกตเวย์เริ่มต้นฝั่งไกล

การกำหนดเส้นทางและการเขียนใหม่ตอบคำถามคนละอย่าง

ตารางเส้นทางตัดสินว่า 172.20.0.0/16 เข้าถึงได้ผ่าน tun0 และการตัดสินนั้นเกิดขึ้นก่อนที่จะปรึกษาการแปล pf ใด ๆ จากนั้นการแปลต้นทางเปลี่ยนหัวแพ็กเก็ตเพื่อให้ปลายทางไกลเห็นที่อยู่ tunnel ของเกตเวย์แทนโฮสต์ LAN ไม่มีกลไกใดแทนที่อีกกลไกหนึ่ง กฎ nat สร้างเส้นทางไม่ได้ และเส้นทางก็โน้มน้าวเราเตอร์ปลายทางที่ไม่เคยได้ยินเกี่ยวกับซับเน็ตส่วนตัวของคุณไม่ได้ เมื่อฝั่งตรงข้ามไม่มีเส้นทางย้อนกลับ คำตอบจะถูกทิ้งหรือส่งต่อไปยังเกตเวย์เริ่มต้นของฝั่งนั้น และการปรับกฎเท่าไรก็ไม่แก้

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

สามเงื่อนไขที่ตัดสิน

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

ถ้าคำตอบใดเป็นไม่หรือไม่ทราบ nat-to คือตัวเลือกที่สมจริง และยังเป็นตัวเลือกที่ย้อนกลับได้ กฎการแปลจะถูกถอดออกในบรรทัดเดียวเมื่อฝั่งตรงข้ามเพิ่มเส้นทางที่เหมาะสม เส้นทางย้อนกลับที่ไม่ได้ติดตั้งไว้เลยจะทำให้คุณต้องตามเรื่องกับฝ่ายสนับสนุนทุกครั้งที่มีคนถามว่าทำไม tunnel ทำงานได้ทางเดียว

วางส่วนย่อยให้ pf ประเมินมันจริง ๆ

ส่วนย่อยด้านล่างถือว่า LAN คือ 192.168.88.0/24 เครือข่ายปลายทางคือ 172.20.0.0/16 และอินเทอร์เฟซ tunnel คือ tun0 ไม่มีสิ่งใดเลือก hop ถัดไป มันเขียนต้นทางใหม่เฉพาะแพ็กเก็ตที่ออกผ่าน tunnel อยู่แล้ว

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

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

อย่าลืมฝั่งเคอร์เนล ต้องเปิดการส่งต่อ IPv4 และกฎ pass แบบมีสถานะสำหรับ tunnel และ LAN ต้องมีอยู่ก่อนที่ทั้งหมดนี้จะมีความหมาย ส่วน PF NAT ใน FAQ ของ OpenBSD เป็นเอกสารอ้างอิงที่ถูกต้องสำหรับลำดับคำสำคัญตรงนี้

ตรวจสอบชุดกฎก่อนที่จะเชื่อถือทราฟฟิก

ตรวจไวยากรณ์ก่อนด้วย pfctl -nf /etc/pf.conf ซึ่งแยกวิเคราะห์ไฟล์โดยไม่โหลด จากนั้นโหลดนโยบายและอ่านกลับสิ่งที่เคอร์เนลถืออยู่จริง เพราะกฎที่แยกวิเคราะห์สะอาดยังอาจถูกบังหรือผูกกับอินเทอร์เฟซผิด pfctl -sn พิมพ์กฎการแปลในรูปแบบที่โหลดแล้ว และ pfctl -sr พิมพ์กฎตัวกรองตามลำดับการประเมิน

จากนั้นดูที่สาย บนเกตเวย์ tcpdump -ni tun0 'host 172.20.0.10' แสดงว่าที่อยู่ต้นทางที่ออกจาก tunnel เป็นที่อยู่ tunnel หรือโฮสต์ LAN netstat -rn -f inet อย่างเร็วจะยืนยันว่าปลายทางแก้เป็นอินเทอร์เฟซใด เมื่อทราฟฟิกเริ่มไหล pfctl -ss จะแสดงรายการสถานะ หากโฟลว์ไม่ได้สร้างสถานะ แพ็กเก็ตนั้นไม่เคยตรงกับกฎที่สร้างสถานะเลย

ถ้าฝั่ง tunnel ดูถูกต้องแต่คำตอบยังไม่มา ให้หยุดแก้ pf ความล้มเหลวที่เหลืออยู่บนเราเตอร์ฝั่งไกล ที่ซึ่งคำตอบถูกส่งไปยังที่อยู่ส่วนตัวที่ฝั่งนั้นเข้าถึงไม่ได้

เมื่อการแปลมีต้นทุนมากกว่าที่ประหยัดได้

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

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

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