กฎ VPN บนเราเตอร์: จับคู่ต้นทางและปลายทาง
กฎ VPN บนเราเตอร์มีสองปลาย: อุปกรณ์ที่ส่งทราฟฟิกและปลายทางที่ควรใช้ทันเนล ตัดสินใจจุดตัดและพฤติกรรมสำรองก่อน
หน้าเว็บซื้อเราเตอร์นำเสนอการกำหนดเส้นทาง VPN เป็นช่องทำเครื่องหมายช่องเดียว และวลีนั้นซ่อนคำถามที่แตกต่างกันสามข้อ กฎนี้ตรงกับอุปกรณ์ที่ส่งทราฟฟิกหรือไม่ ตรงกับเซิร์ฟเวอร์ที่รับหรือไม่ หรือตรงกับทั้งสองอย่าง ทราฟฟิกที่ไม่ตรงกับทั้งสองอย่างจะเป็นอย่างไร และเมื่อกฎสองข้อทับซ้อนกัน ข้อใดชนะ การเขียนคำตอบเป็นคู่ของต้นทางและปลายทางเปลี่ยนรายการฟีเจอร์ที่คลุมเครือให้เป็นการออกแบบที่ทดสอบได้
ชื่อฟีเจอร์ซ่อนสองปลาย
เครื่องเล่นมีเดียที่ควรใช้ทันเนลคือการจับคู่ต้นทาง คำนำหน้าสำนักงานส่วนตัวที่ควรเข้าถึงได้ผ่านทันเนลคือการจับคู่ปลายทาง สถานีงานที่ควรใช้ทันเนลเพียงบริการเดียวคือทั้งสองอย่าง และจุดตัดนั้นคือ กรณีที่เฟิร์มแวร์ผู้บริโภคส่วนใหญ่จัดการได้ไม่ดี
เขียนความต้องการเป็นคู่ก่อนเปรียบเทียบผลิตภัณฑ์ คู่นั้นคือสิ่งที่คุณจะทดสอบในภายหลัง
ผลิตภัณฑ์ที่เสนอรายการอุปกรณ์หรือรายการปลายทางระดับโลกอาจไม่สามารถแสดง «เฉพาะอุปกรณ์นี้ เฉพาะปลายทางเหล่านี้» ช่องว่างนี้ไม่ใช่เรื่องผิวเผิน กฎปลายทางระดับโลกส่งทราฟฟิกของทุกอุปกรณ์ไปยังไซต์นั้นผ่านทันเนล และกฎอุปกรณ์ส่งทราฟฟิกทั้งหมดของอุปกรณ์นั้น ทั้งสองอย่างไม่ใช่ความต้องการ ทดสอบกรณีนั้นด้วยอุปกรณ์สองเครื่องก่อนเชื่อหน้าจอ
สร้างกฎเป็นจุดตัด
ตารางทำให้การออกแบบซื่อสัตย์ วางสถานการณ์ไว้ทางซ้าย แล้วตั้งชื่อการจับคู่ผู้ส่งและการจับคู่เป้าหมายแยกกัน
| Scenario | Sender match | Target match | Rule shape |
|---|---|---|---|
| Media player uses the tunnel | Player address | Any internet destination except the LAN | Source only |
| Office prefix reachable | Authorized LAN devices | 10.40.0.0/16 | Target only |
| One app on one laptop | Laptop address | The service address set | Source and target |
| Guest network never tunnels | Guest subnet | Any | Deny, evaluated first |
แถวที่สามน่าสนใจเพราะต้องใช้ทั้งสองครึ่งพร้อมกัน หากเฟิร์มแวร์แสดงได้เพียงแกนเดียว ความต้องการต้องแยกเป็นสองกฎหรือย้ายไปยังอุปกรณ์ที่ทำได้
รักษาเอกลักษณ์ของต้นทางให้คงที่ การจอง DHCP เซกเมนต์เฉพาะหรือกลไกเอกลักษณ์อุปกรณ์ทำงานได้ แต่ที่อยู่ที่เปลี่ยนหลังสัญญาเช่าหมดอายุใช้ไม่ได้ รวม IPv6 ด้วย เพราะที่อยู่ IPv4 หนึ่งรายการไม่ได้ระบุทราฟฟิกทั้งหมดของอุปกรณ์
ลำดับความสำคัญเป็นตัวตัดสินการทับซ้อน
กฎที่ทับซ้อนกันเป็นเรื่องปกติ กฎอุปกรณ์แบบกว้างและกฎปลายทางแบบแคบอาจอธิบายการไหลเดียวกันได้ และลำดับความสำคัญที่บันทึกไว้เป็นตัวตัดสินว่าข้อใดชนะ หน้าจอการตั้งค่าที่สวยงามไม่ได้บอกลำดับนั้นกับคุณ
อ่านคู่มือเรื่องลำดับและกรณีที่ไม่ตรงกัน แล้วทดสอบทั้งสองด้วยทราฟฟิกที่คุณสังเกตได้
ip rule show
ip route get 203.0.113.10หากเอกสารไม่ได้ระบุลำดับ ให้ถือว่ากฎที่แคบกว่าอาจไม่ชนะและออกแบบโดยคำนึงถึงสิ่งนั้น สองกฎที่ไม่สามารถขัดกันได้นั้นรองรับได้ง่ายกว่ากฎฉลาดหนึ่งข้อที่มีลำดับความสำคัญไม่ได้บันทึกไว้
ชื่อต้องมีนโยบายการรีเฟรช
ปลายทางที่เขียนเป็นโดเมนเพิ่มปัญหาการบำรุงรักษา เราเตอร์ต้องแก้ไข รีเฟรชการแมป จัดการหลายที่อยู่และซับโดเมน และรับมือกับ DNS ของแอปพลิเคชันที่เลี่ยงตัวแก้ไขที่คาดไว้
การคัดลอกผลการค้นหาหนึ่งรายการลงในกฎ IP คือภาพนิ่ง ไม่ใช่นโยบายโดเมน
ตัดสินว่าคำตอบเก่าได้แค่ไหนก่อนที่กฎจะผิด และเราเตอร์ทำอะไรเมื่อการแก้ไขล้มเหลว กฎที่เก็บที่อยู่ที่รู้ล่าสุดอาจอยู่รอดจากการย้ายบริการ กฎที่ทิ้งรายการอาจหยุดการทำทันเนลอย่างเงียบ ๆ ทั้งสองพฤติกรรมยอมรับได้หากเขียนไว้ข้างกฎ
กำหนดสถานะที่ไม่พร้อมใช้งาน
การตั้งค่าเส้นทางไม่ได้บังคับทราฟฟิกเฉพาะ VPN เมื่อทันเนลล่ม เราเตอร์อาจบล็อกการไหล ส่งโดยตรง หรือใช้ทันเนลอื่น และแต่ละทางเลือกมีลายเซ็นความล้มเหลวต่างกัน
ตัดสินว่าความต้องการต้องใช้ข้อใด แล้วตรวจสอบโดยหยุดทันเนลและสังเกตการไหล
curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://service.example/
ping -c 2 203.0.113.10ทราฟฟิกที่เกิดจากเราเตอร์เองเป็นขอบเขตแยกต่างหาก การส่งต่อ DNS การตรวจสอบอัปเดต และการเฝ้าติดตามอาจเริ่มการไหลใหม่จากเราเตอร์เองแทนที่จะสืบทอดการจับคู่ต้นทางของอุปกรณ์ คำนึงถึงการไหลเหล่านั้นอย่างชัดเจน มิฉะนั้นจะปรากฏเป็นการรั่วไหลที่อธิบายไม่ได้ในบันทึก