โซน VPN ของ OpenWrt การส่งต่อ และมาสค์เกอเรด: ต้องใช้อันไหน?
อินพุตโซน การส่งต่อ และมาสค์เกอเรดตอบคำถามต่างกัน ตัดสินใจว่าทราฟฟิก VPN ของคุณต้องการสิ่งใดก่อนเปิดโซน WAN
การเปลี่ยนแปลงสามอย่างมักถูกปนกันทุกครั้งที่ VPN เจอกับ OpenWrt ได้แก่ การเปิดพอร์ต การอนุญาตให้ส่งต่อ และการเปิดมาสค์เกอเรด ทั้งสามตอบคำถามต่างกัน และโดยปกติมีเพียงอย่างเดียวที่เป็นข้อกำหนดจริง การอ่านแต่ละส่วนควบคุมตามบทบาทของทราฟฟิกที่มันกำกับจะเปลี่ยนการเดาให้เป็นการตัดสินใจ และยังบอกว่าควรคาดหวังอาการใดเมื่อการเปลี่ยนแปลงผิดพลาด เริ่มจากการระบุบทบาทที่ล้มเหลว ไม่ใช่ช่องทำเครื่องหมายที่คุณจำได้
ระบุบทบาทของทราฟฟิกก่อนแตะส่วนควบคุม
อินพุตโซนกำหนดว่าอะไรเข้าถึงตัวเราเตอร์ได้ เอาต์พุตโซนครอบคลุมทราฟฟิกที่เราเตอร์สร้างเอง การส่งต่อโซนเป็นค่าเริ่มต้นสำหรับทราฟฟิกที่ผ่านโซน และมาสค์เกอเรดกำหนดว่าจะเขียนที่อยู่ต้นทางใหม่ตอนออกหรือไม่ นี่คือสี่คำถามที่ต่างกัน และนโยบายโซนตอบทั้งสี่พร้อมกันด้วยค่าเดียวกัน จึงเป็นการเปลี่ยนแปลงทั้งโซนจึงเป็นเครื่องมือที่หยาบ กฎที่มีชื่อสามารถตอบข้อใดข้อหนึ่งได้โดยไม่แตะข้ออื่น
แผนที่ที่มีประโยชน์คือแบ่งตามบทบาทของทราฟฟิก เพราะนั่นคือสิ่งที่สังเกตได้เมื่อมีบางอย่างล้มเหลว บทบาทแต่ละข้อด้านล่างมีส่วนควบคุมหนึ่งอย่างที่กำหนดมัน และมีอาการหนึ่งอย่างที่ชี้มาที่มัน
| Traffic role | Control that decides it | Where it lives in the config | Symptom when it is wrong |
|---|---|---|---|
| A client reaching a listener on the router | Input policy of the zone that carries the connection, or a rule for the port | option input in the zone stanza, or a named rule | The handshake never completes and the tunnel log says nothing |
| A tunnel client reaching the router itself | Input policy of the tunnel zone | option input in the VPN zone | A ping to the gateway fails |
| A tunnel client reaching another LAN host | Forwarding from the tunnel zone to the LAN zone | config forwarding plus the zone assignment | The gateway answers and the file share times out |
| The router's own traffic leaving the WAN | Output policy, and translation if the far side needs it | option output and option masq | The tunnel never establishes, or replies vanish |
ตัวรับฟังบนเราเตอร์ต้องการกฎอินพุตแคบเพียงข้อเดียว
เซิร์ฟเวอร์ OpenVPN บนเราเตอร์รับทราฟฟิกที่ส่งมาที่เราเตอร์ ดังนั้นการเชื่อมต่อภายนอกขึ้นอยู่กับนโยบายอินพุตของโซนที่พามันมา อนุญาตโปรโตคอลขนส่งและพอร์ตที่กำหนด และปล่อยให้ทุกอย่างอื่นในโซนนั้นถูกปฏิเสธ กฎพอร์ตเพียงข้อเดียวเป็นการเปลี่ยนแปลงที่เล็กกว่าการอนุญาตทั้งโซนมาก และเป็นสิ่งที่คุณยังอธิบายได้แม้ผ่านไปหนึ่งปี
สองสิ่งทำให้กฎนั้นปลอดภัยพอจะเก็บไว้ คือมันระบุพอร์ตที่บริการใช้จริง และมันวางอยู่ข้างนิยามโซนเพื่อให้คนถัดไปเห็นว่าทำไมมันจึงมีอยู่ บรรทัดด้านล่างเป็นเพียงรูปแบบ โดยพอร์ตแทนสิ่งที่กำหนดไว้บนเซิร์ฟเวอร์ เปลี่ยนพอร์ตนั้นทั้งสองที่เมื่อบริการย้าย เพราะกฎที่ค้างอยู่บนพอร์ตเก่าจะมองไม่เห็นจนกว่าจะมีการตรวจสอบ
config zone
option name 'wan'
option input 'REJECT'
option forward 'REJECT'
option output 'ACCEPT'
option masq '1'
config rule
option name 'allow-openvpn'
option src 'wan'
option proto 'udp'
option dest_port '1194'
option target 'ACCEPT'ตรวจสอบก่อนโหลดใหม่ เพราะข้อผิดพลาดทางไวยากรณ์ในไฟล์ไฟร์วอลล์อาจทำให้เราเตอร์ไม่มีชุดกฎที่ใช้งานได้ ในรุ่นที่ใช้ fw4 การตรวจสอบเป็นคำสั่งแยก และมันล้มเหลวอย่างดังแทนที่จะยอมรับบล็อกที่เสียหายอย่างเงียบ ๆ โหลดใหม่เฉพาะหลังจากตรวจสอบผ่านแล้ว และเก็บไฟล์ก่อนหน้าไว้ในที่ที่คุณใส่กลับได้
fw4 check
service firewall reloadคำขอของไคลเอนต์ผ่านการส่งต่อ ไม่ใช่อินพุต
หลังการยืนยันตัวตน คำขอของไคลเอนต์อุโมงค์สำหรับบริการ LAN สร้างโฟลว์ที่ถูกส่งต่อ ดังนั้นส่วนควบคุมที่กำหนดมันคือความสัมพันธ์การส่งต่อระหว่างโซนอุโมงค์กับโซน LAN กำหนดอินเทอร์เฟซอุโมงค์ให้โซนที่ต้องการ แล้วประกาศทิศทาง แหล่งที่มา และบริการ การกำหนดโซนคือสิ่งที่ให้ความหมายกับกฎการส่งต่อ และทั้งสองเข้าใจได้ก็ต่อเมื่ออ่านด้วยกัน ความสัมพันธ์การส่งต่อที่ระบุโซนอุโมงค์เป็นแหล่งที่มาและโซน LAN เป็นปลายทางอ่านได้เป็นการตัดสินใจที่ตั้งใจครั้งเดียว ขณะที่การอนุญาตทั้งโซนสองครั้งอ่านได้ว่าเป็นอุบัติเหตุ
การเข้าถึงตัวเราเตอร์ยังใช้เส้นทางอินพุต นี่คือเหตุผลที่ ping ไปยังเกตเวย์ไม่บอกอะไรเกี่ยวกับการแชร์ไฟล์ที่อยู่ข้างหลัง ความล้มเหลวสองอย่างนั้นอยู่ในบล็อกต่างกันและแก้ด้วยการเปลี่ยนแปลงต่างกัน เขียนทั้งสองเส้นทางแยกกันก่อนเปลี่ยนอย่างใดอย่างหนึ่ง
มาสค์เกอเรดเป็นการตัดสินใจเรื่องเส้นทาง ไม่ใช่การอนุญาต
มาสค์เกอเรดเขียนที่อยู่ต้นทางของทราฟฟิกขาออกที่เลือกใหม่ มันช่วยกู้การออกแบบทางออกที่ฝั่งไกลไม่มีเส้นทางกลับได้ และยังซ่อนที่อยู่ของไคลเอนต์แต่ละรายจากบริการใดก็ตามที่บันทึกหรืออนุญาตตามที่อยู่ การปิดมันเป็นการเลือกเส้นทางเกี่ยวกับเส้นทางกลับ ไม่ใช่สวิตช์ความปลอดภัยที่ปิดรูรั่วขาเข้า อุโมงค์ที่ทำงานเมื่อเปิดการแปลที่อยู่และล้มเหลวในนาทีที่ปิดมักขาดเส้นทางกลับ ไม่ใช่ขาดกฎไฟร์วอลล์
ทางเลือกที่กำหนดเส้นทางต้องมีเส้นทางกลับที่ฝั่งไกลแทนการแปลที่อยู่ ไม่มีตัวเลือกใดให้สิทธิ์ไฟร์วอลล์หรือบัญชีแอปพลิเคชัน นี่คือเหตุผลที่การปิดมาสค์เกอเรดแทบไม่เคยแก้ไคลเอนต์อุโมงค์ที่ไปไม่ถึงไหนได้เลย ให้จัดการนโยบาย IPv4 และ IPv6 แยกกันด้วย เพราะการตั้งค่าการแปลเพียงอย่างเดียวไม่ได้อธิบายทั้งสองตระกูล
พิสูจน์การตัดสินใจด้วยคำขอที่อนุญาตและที่ถูกปฏิเสธ
ส่งคำขอหนึ่งที่ควรได้รับอนุญาตและอีกหนึ่งที่ควรถูกปฏิเสธ แล้วระบุส่วนควบคุมที่ตัดสินใจในแต่ละครั้ง หน้าที่โหลดขึ้นมาโดยบังเอิญไม่ใช่หลักฐาน หลักฐานคือกฎที่ตรงกัน ในเชนที่มันตรงกัน การปฏิเสธสำคัญพอ ๆ กับความสำเร็จ เพราะมันแสดงว่านโยบายกำลังทำอะไรบางอย่าง ไม่ใช่ทุกอย่างได้รับอนุญาต
สองคำสั่งให้หลักฐานนั้นในรุ่นปัจจุบัน ตัวนับบนกฎที่ตรงกันจะขยับเมื่อคำขอได้รับการยอมรับ และบันทึกจะแสดงการทิ้งหากคุณเปิดการบันทึกสำหรับกฎนั้น
nft list chain inet fw4 forward_wan
logread -f | grep -i -E 'DROP|REJECT'เก็บเส้นทางบริหารที่ยังใช้ได้ไว้ก่อนเปลี่ยนนโยบายไฟร์วอลล์ใด ๆ และทำตามกระบวนการตรวจสอบและย้อนกลับของเจ้าของการกำหนดค่า การเปลี่ยนแปลงที่ล็อกคุณออกจากเราเตอร์ไม่ใช่ผลการทดสอบแต่เป็นเหตุการณ์ที่สอง บันทึกโซนและบทบาทของทราฟฟิกข้างการสังเกตแต่ละครั้ง เพื่อให้ผลลัพธ์คู่หนึ่งอธิบายนโยบายแทนที่จะบรรยายการโหลดหน้าที่โชคดี