VPN แบบไซต์ทูไซต์กับแบบรีโมตแอ็กเซส: แต่ละแบบเชื่อมอะไร
แบบหนึ่งเชื่อมเกตเวย์ อีกแบบเชื่อมอุปกรณ์ เทียบตัวเลือกทราฟฟิกกับเส้นทาง วางแผนการกำหนดแอดเดรส แล้วทดสอบการส่งต่อและนโยบายจากโฮสต์จริง
ทั้งสองแบบเรียกว่า VPN และแก้ปัญหาต่างกัน ทันเนลแบบไซต์ทูไซต์เชื่อมเกตเวย์สองตัว ดังนั้นทุกโฮสต์ที่อยู่ข้างหลังจึงเข้าถึงแอดเดรสที่อนุญาตอีกฝั่งได้โดยไม่ต้องติดตั้งอะไร ทันเนลแบบรีโมตแอ็กเซสเชื่อมอุปกรณ์ทีละเครื่องเข้ากับเครือข่าย ทีละไคลเอนต์ การเปรียบเทียบนี้สำคัญเพราะข้อผิดพลาดในการติดตั้งส่วนใหญ่เกิดจากการกำหนดค่าของแบบหนึ่งแต่คาดหวังพฤติกรรมของอีกแบบ และอาการที่เห็นมักเป็นการหมดเวลาในบริการที่ทันเนลไปถึงจริง
สองแบบ สองขอบเขต
| Site-to-site | Remote access | |
|---|---|---|
| Endpoints | two gateways | a gateway and each client |
| Who configures | network owners | each user or an MDM |
| Scope of reach | whatever the gateways route | whatever the client is granted |
| Broadcast discovery | not carried | not carried |
ไม่มีแบบใดขยายบรอดแคสต์โดเมนของ LAN อุปกรณ์อีกฝั่งจะไม่ปรากฏในรายการค้นหาภายในเครื่อง และการคาดหวังให้เป็นเช่นนั้นคือสมมติฐานแรกที่ต้องทิ้ง ชื่อ DNS ภายในที่คุณเผยแพร่โดยเจตนาคาดเดาได้มากกว่าพร็อโตคอลค้นหาใด ๆ และยังคงอยู่แม้เปลี่ยนผู้ให้บริการ
ใช้ 10.10.0.0/24 ที่ไซต์หนึ่งและ 10.20.0.0/24 ที่อีกไซต์ เกตเวย์ A ต้องมีเส้นทางหรือตัวเลือกทราฟฟิกที่ส่งคำนำหน้า 10.20.0.0/24 เข้าไปในทันเนล และเกตเวย์ B ต้องมีภาพสะท้อนของสิ่งนั้น จากนั้นโฮสต์ทั้งสองฝั่งใช้การเชื่อมต่อ IP ธรรมดาและไม่เคยรู้ว่ามีทันเนลอยู่ ความล่องหนนั้นคือคุณสมบัติ และเป็นเหตุผลที่ความล้มเหลวดูเหมือนข้อผิดพลาดเครือข่ายทั่วไปไม่ใช่ข้อผิดพลาดของทันเนล
แบบอิงนโยบายกับแบบอิงเส้นทางไม่ใช่ทันเนลเดียวกัน
ในการติดตั้ง IPsec แบบอิงนโยบาย ตัวเลือกทราฟฟิกที่เจรจาแล้วกำหนดอย่างชัดเจนว่าคู่ต้นทางและปลายทางใดได้รับการป้องกัน หากมีซับเน็ตใหม่ปรากฏขึ้นข้างหลังเกตเวย์ตัวหนึ่งและไม่มีตัวเลือกใดครอบคลุม ทันเนลจะยังทำงานอยู่และซับเน็ตใหม่นั้นก็ไม่ถูกส่งต่อ ในดีไซน์แบบอิงเส้นทาง อินเทอร์เฟซเป็นตัวรับทราฟฟิกและตารางเส้นทางเป็นตัวตัดสิน ซึ่งทำให้ การเพิ่มคำนำหน้าเป็นการเปลี่ยนเส้นทางไม่ใช่การเจรจาทันเนลใหม่
StrongSwan แสดงมุมมองทั้งสองโดยตรง และการอ่านทั้งสองร่วมกันคือวิธีรู้ว่าคุณติดตั้งโมเดลใดจริง
swanctl --list-sas
ip xfrm policy
ip -4 route show table all | grep -E '10\.(10|20)\.'รายการตัวเลือกที่ไม่มีความนำหน้าที่คุณต้องการอธิบายความล้มเหลวได้โดยไม่ต้องดักแพ็กเก็ตเลย และเส้นทางที่ชี้ไปยังอินเทอร์เฟซผิดอธิบายความล้มเหลวแบบกระจกขากลับ อ่านทั้งสองก่อนเจรจาอะไรใหม่ เพราะการต่ออายุคีย์จะไม่เพิ่มตัวเลือกที่คุณไม่เคยกำหนดค่า
วางแผนการกำหนดแอดเดรสก่อนสร้างทันเนล
ช่วงที่ทับซ้อนกันคือข้อผิดพลาดการออกแบบที่แก้ด้วยการกำหนดค่าไม่ได้ หากทั้งสองไซต์ใช้ 192.168.1.0/24 โฮสต์ที่ต้องการ 192.168.1.50 จะมีผู้สมัครสองรายและไม่มีวิธีเลือก ทันเนลจะยืนยันตัวตนได้ ความเชื่อมโยงด้านความปลอดภัยจะถูกสร้างขึ้น และการตัดสินเส้นทางก็ยังผิดหรือกำกวมอยู่ดี
เลือกหนึ่งในสามทางที่ซื่อตรง: กำหนดเลขใหม่ให้ไซต์หนึ่ง แปลงช่วงที่ทับซ้อนที่เกตเวย์เพื่อให้แต่ละฝั่งเห็นคำนำหน้าแตกต่างกัน หรือเลิกใช้เส้นทางตรงสำหรับโฮสต์เหล่านั้นแล้วเผยแพร่บริการด้วยวิธีอื่น แต่ละทางมีต้นทุน และทางแรกมักถูกที่สุดในระยะสองปี ตัดสินใจก่อนทันเนลจะมีอยู่ เพราะหลังจากนั้นการเปลี่ยนแปลงจะกระทบทุกอุปกรณ์ที่มีแอดเดรสเดิม
แก้ปัญหา MTU แต่เนิ่น ๆ ด้วย ทันเนลลดเพย์โหลดที่ใช้ได้ และดีไซน์ที่พึ่งการแบ่งแพ็กเก็ตมีพฤติกรรมต่างจากดีไซน์ที่ตรึง MSS ที่เกตเวย์
การส่งต่อและนโยบายอยู่ภายนอกทันเนล
เกตเวย์ต้องยินยอมส่งต่อแพ็กเก็ตระหว่างอินเทอร์เฟซของทันเนลกับอินเทอร์เฟซ LAN และทั้งสองทิศทางต้องมี นโยบายที่อนุญาตบริการ ใน Linux สิ่งเหล่านี้เป็นการตั้งค่าสองอย่างแยกกัน บวกกับกฎไฟร์วอลล์ที่ตัดสินว่าการไหลที่ถูกส่งต่อนั้นได้รับอนุญาตหรือไม่
sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -s 10.20.0.0/24 -d 10.10.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.10.0.0/24 -d 10.20.0.0/24 -j ACCEPTโฮสต์ปลายทางเพิ่มชั้นที่สาม: ไฟร์วอลล์ของมันเองยังต้องยอมรับไคลเอนต์จากซับเน็ตระยะไกล เซิร์ฟเวอร์ไฟล์ที่อนุญาตเฉพาะ /24 ภายในของตนจะปฏิเสธทราฟฟิกที่ส่งต่อมาจาก 10.20.0.7 ไม่ว่าทันเนลจะดูแข็งแรงเพียงใด และการปฏิเสธนั้นอ่านผิดว่าเป็นความล้มเหลวของเส้นทางได้ง่าย
ทดสอบจากโฮสต์ ไม่ใช่จากเกตเวย์
ping ที่เกตเวย์เองเป็นผู้ส่งอาจใช้แอดเดรสต้นทางและนโยบายต่างจากทราฟฟิกผู้ใช้ที่ถูกส่งต่อ ทำให้เป็นการทดสอบที่อ่อนและบางครั้งก็ชวนเข้าใจผิด: สำเร็จในขณะที่แอปพลิเคชันล้มเหลว หรือล้มเหลวในขณะที่แอปพลิเคชันทำงาน
ip route get 10.10.0.5 from 10.20.0.7
ping -I 10.20.0.7 10.10.0.5
curl -sv --max-time 5 http://files.10-10.internal/ -o /dev/nullใช้โฮสต์จริง แอดเดรสต้นทางจริง และพร็อโตคอลจริงที่แอปพลิเคชันใช้ จากนั้นอ่านเส้นทางขากลับแยกต่างหาก เพราะทิศทางขาไปที่ทำงานได้โดยไม่มีเส้นทางขากลับจะสร้างการหมดเวลาที่ดูเหมือนบริการที่ถูกบล็อกทุกประการ
เลือกดีไซน์ตามคำถามที่คุณกำลังตอบ: คุณกำลังเชื่อมเครือข่ายหรือรับอุปกรณ์เข้า ทุกอย่างอื่นรวมถึงผู้ให้บริการที่คุณกำหนดค่าก็มาจากคำตอบนั้น