เส้นทางหนึ่งซับเน็ต LAN ผ่าน OpenVPN และเก็บเส้นทางเริ่มต้นไว้
เก็บเส้นทางเริ่มต้นของ LAN ไว้ขณะที่ซับเน็ตหนึ่งวิ่งผ่านอุโมงค์ เปรียบเทียบตารางนโยบายกับการแก้ไขตารางหลัก แล้วเลือก NAT หรือเส้นทางฝั่งเซิร์ฟเวอร์
อุปกรณ์ที่เราต์สำหรับ LAN และหมุน VPN ไปพร้อมกันมักเถียงกับตัวเองในเรื่องเดียวกัน อุโมงค์ต้องการเป็นเจ้าของเส้นทางเริ่มต้น ขณะที่ LAN ต้องการมันคืน เมื่อ OpenVPN เชื่อมต่อ อาจติดตั้งเส้นทางเริ่มต้นผ่านอุโมงค์หรือเส้นทางครึ่งเริ่มต้นสองเส้น ซึ่งถูกสำหรับแล็ปท็อปแต่ผิดสำหรับเกตเวย์ที่เพื่อนบ้านคาดหวังคำตอบจากที่อยู่ LAN ของมัน คำตอบไม่ใช่การข้าม VPN ไป คำตอบคือการให้การตัดสินใจสองเรื่องใช้ตารางคนละใบ
เส้นทางเริ่มต้นหนึ่งเส้น เจ้าของสองราย
ทราฟฟิกที่ส่งต่อกับทราฟฟิกที่เกิดขึ้นในเครื่องไม่จำเป็นต้องไปเส้นทางเดียวกัน ไคลเอนต์ LAN ต้องการอุโมงค์เฉพาะปลายทางที่คุณเลือก ขณะที่เซสชันการจัดการของโฮสต์เองและคำตอบที่ส่งกลับให้ไคลเอนต์เหล่านั้นต้องการเส้นทางเริ่มต้นของ LAN การผสมทั้งสองอย่างไว้ในตารางหลักบังคับให้คำตอบเดียวต้องตอบคำถามที่ต่างกันสองข้อ
OpenVPN มีสวิตช์สำหรับเรื่องนี้โดยเฉพาะ route-noexec ป้องกันไม่ให้ไคลเอนต์แตะตารางหลักเลย และค่าที่มันจะใช้ถูกส่งออกไปยังสคริปต์ route-up ในชื่อ route_vpn_gateway, dev และที่อยู่ของอินเทอร์เฟซ จากนั้นคุณเป็นคนตัดสินใจว่าตารางไหนได้รับเส้นทางไหน ในโค้ดที่อ่านย้อนหลังได้
ตารางนโยบายกับการเขียนตารางหลักใหม่
| Approach | What it buys | What it costs |
|---|---|---|
| Separate table plus source rule | LAN traffic and host traffic keep independent defaults | Every lookup now depends on rule order |
| Editing the main table only | Fewer moving parts on a single-purpose host | One mistake takes the gateway offline entirely |
| Two half-default routes | Works for a full-tunnel client | Ambiguous on a host that must answer on its LAN address |
ตารางแยกเป็นทางเลือกเดียวที่ขยายได้เกินหนึ่งซับเน็ต ตั้งชื่อให้มันครั้งเดียว แล้วอ้างอิงด้วยชื่อ เพื่อให้ไม่มีใครต้องจำตัวเลข
echo "10 vpn" >> /etc/iproute2/rt_tables
ip rule add from 192.168.50.0/24 table vpn
ip route add default via 10.8.0.1 dev tun0 table vpnที่อยู่ในที่นี้เป็นตัวแทน เปลี่ยนคำนำหน้า LAN เกตเวย์ของอุโมงค์ และชื่ออุปกรณ์จากการติดตั้งของคุณก่อนรันอะไรก็ตาม
กฎต้องตรงกับโฮสต์ด้วย
กฎที่ตรงกับคำนำหน้า LAN เท่านั้นครอบคลุมแพ็กเก็ตที่ส่งต่อ มันไม่ครอบคลุมทราฟฟิกที่เกตเวย์สร้างเอง และไม่ครอบคลุมคำตอบที่ส่งกลับไปยังไคลเอนต์ LAN ซึ่งมีที่อยู่ LAN ของเกตเวย์เป็นต้นทาง การค้นหาเหล่านั้นตกไปที่ main และยังออกผ่านอุโมงค์ได้
เพิ่มกฎที่สองสำหรับที่อยู่ LAN ของเกตเวย์เอง หรือขยายกฎแรกให้เป็นชุดที่รวมทั้งสองอย่าง ลำดับสำคัญ วางกฎที่เจาะจงกว่าไว้ก่อน แล้วตรวจผลด้วยการค้นหาที่ระบุต้นทางอย่างชัดเจน
ip route get 203.0.113.9 from 192.168.50.1ถ้ามันรายงานอุปกรณ์อุโมงค์สำหรับปลายทางที่ควรอยู่ภายใน นั่นแปลว่าชุดกฎผิด ไม่ว่าตารางจะมีอะไรอยู่
NAT หรือเส้นทางที่ฝั่งไกล
เซิร์ฟเวอร์ VPN รู้จักซับเน็ตของอุโมงค์และไม่รู้อะไรอื่น แพ็กเก็ตที่มาพร้อมที่อยู่ต้นทางของ LAN ไม่มีทางกลับเว้นแต่มีใครจัดหาให้ และมีวิธีจัดหาเพียงสองวิธีเท่านั้น การเพิ่มเส้นทางสำหรับคำนำหน้า LAN บนเซิร์ฟเวอร์ทำให้ต้นทางเดิมมองเห็นได้ตลอดเส้นทาง ซึ่งการออกแบบที่ผ่านการตรวจสอบมักต้องการ การทำมาสค์เกอเรดบนเกตเวย์เขียนต้นทางใหม่เป็นที่อยู่ของอุโมงค์และไม่ต้องอาศัยความร่วมมือจากเซิร์ฟเวอร์
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADEเลือก NAT เมื่อคุณไม่ได้ควบคุมเซิร์ฟเวอร์และเพิ่มเส้นทางที่นั่นไม่ได้ เลือกเส้นทางฝั่งเซิร์ฟเวอร์เมื่อบันทึก การควบคุมการเข้าถึง หรือความสมมาตรของเส้นทางขากลับมีความสำคัญ เพราะการมาสค์เกอเรดลบที่อยู่เดิมออกจากทุกสิ่งที่ฝั่งไกลบันทึก
ไม่ว่าทางไหน การส่งต่อต้องเปิดใช้งาน และการกรองเส้นทางย้อนกลับแบบเข้มงวดอาจทิ้งคำตอบเมื่อ main ไม่ได้เลือกอุโมงค์สำหรับต้นทางนั้น ตรวจสอบค่าที่มีผลจริงก่อนโทษอุโมงค์
ทำให้การแยกอยู่รอดหลังเชื่อมต่อใหม่
กฎและเส้นทางที่เพิ่มด้วยมือจะหายไปเมื่ออินเทอร์เฟซถูกสร้างใหม่ และรายการตารางเก่าอาจอยู่นานกว่าเซสชันที่ทำให้มันสมเหตุสมผล ใส่กฎของตาราง เส้นทางของอุโมงค์ และรายการมาสค์เกอเรดไว้ในสคริปต์ route-up ของไคลเอนต์ แล้วล้างตารางที่ต้นสคริปต์ เพื่อไม่ให้เกตเวย์เก่าอยู่รอดเข้าไปในเซสชันใหม่
ตรวจสอบจากทั้งสองด้าน การค้นหาบนเกตเวย์ด้วยต้นทาง LAN และคำขอจริงจากไคลเอนต์ LAN ไปยังปลายทางที่ควรผ่านอุโมงค์ เส้นทางที่มีอยู่แต่ไม่เคยถูกเลือกจะทำงานเหมือนไม่มีเส้นทางเลย จนกว่าคุณจะอ่านตัวนับ