เพิ่มซับเน็ตที่สองให้ VPN เชื่อมระหว่างไซต์: สองเส้นทาง
อุโมงค์ที่ใช้policyต้องมีตัวเลือกที่ตรงกันทั้งสองฝั่ง ส่วนแบบใช้เส้นทางต้องมีเส้นทาง เลือกเส้นทางที่ถูกและแก้เส้นทางขากลับก่อน
การเพิ่มซับเน็ตที่สองให้อุโมงค์ระหว่างไซต์ที่ทำงานอยู่ใช้เวลาห้านาทีในดีไซน์หนึ่งและเกือบทั้งบ่ายในอีกดีไซน์หนึ่ง เมื่ออุโมงค์ติดตั้งเส้นทางสำหรับคำนำหน้าที่คุณระบุ คุณก็เพิ่มเส้นทางและทราฟฟิกก็ตามไป เมื่อมันเจรจาคู่ตัวเลือกคงที่คู่เดียว คำนำหน้าใหม่จะไม่ได้รับการป้องกันจนกว่าทั้งสองฝั่งจะตกลงคู่ที่ตรงกัน มีสามสิ่งตัดสิน: ค่าคอนฟิกของแต่ละฝั่งอธิบายอะไรจริง ๆ ทราฟฟิกที่เจรจาแล้วถูกจำกัดให้แคบลงถึงคู่ที่ตรงกันเล็กที่สุดหรือไม่ และใครเป็นเจ้าของเส้นทางขากลับของช่วงใหม่
อ่านเคอร์เนล ไม่ใช่อ่านป้ายสถานะ
อุโมงค์ที่รายงานว่าเชื่อมต่อได้ติดตั้งอย่างน้อยหนึ่งแอสโซซิเอชันลูก แต่ไม่จำเป็นต้องเป็นตัวที่คุณคิด บน Linux เคอร์เนลแสดงสิ่งที่ถูกใช้: ip xfrm policy แสดงคู่ตัวเลือก และ swanctl --list-sas (หรือ ipsec statusall รุ่นเก่า) แสดงสิ่งที่ทั้งสองฝั่งเจรจากัน รวมถึงตัวเลือกทราฟฟิกในแต่ละทิศทาง ถ้าคำนำหน้าใหม่ไม่ปรากฏในทั้งสองอย่าง มันก็ไม่ได้รับการป้องกัน ไม่ว่าไฟล์คอนฟิกจะพูดอย่างไร
เทียบกับตารางเส้นทาง ในการออกแบบที่ใช้เส้นทาง อุปกรณ์อุโมงค์คือฮอปถัดไปของคำนำหน้าที่ได้รับการป้องกัน การออกแบบที่ใช้policyมักไม่มีเส้นทางเฉพาะสำหรับซับเน็ตปลายทาง มีเพียงเส้นทางเริ่มต้น เพราะpolicyเป็นตัวเลือกทราฟฟิกไม่ใช่ตาราง
แบบใช้policy: ทั้งสองฝั่งต้องระบุคำนำหน้าใหม่
ในศัพท์ของ strongSwan ตัวเลือกอยู่ใน local_ts และ remote_ts ใต้คอนฟิกลูก ซึ่งเป็นตัวสืบทอดของ leftsubnet และ rightsubnet คำนำหน้าใหม่ต้องปรากฏทั้งสองฝั่งแบบกระจก: สิ่งที่ไซต์ A เรียกว่าโลคัล ไซต์ B เรียกว่าระยะไกล ความไม่ตรงกัน seldom ให้ข้อผิดพลาดที่ชัดเจน ทั้งสองฝั่งแคบลงถึงส่วนตัดกัน คำนำหน้าเก่ายังทำงาน มีเพียงตัวใหม่ที่ล้มเหลวอย่างเงียบ ๆ
swanctl --load-conns
swanctl --initiate --child <child-name>
swanctl --list-sas
ip xfrm policyบน pfSense หรือ OPNsense นั่นหมายถึงรายการ Phase 2 รายการที่สองที่จับคู่ซับเน็ตโลคัลใหม่กับซับเน็ตระยะไกลใหม่ แล้วจึงนำไปใช้ เก็บรายการเก่าไว้ การแทนที่จะย้ายซับเน็ตเดิมแทนที่จะเพิ่ม ถ้า Phase 2 ที่มีอยู่ครอบคลุมซูเปอร์เน็ตอย่าง 0.0.0.0/0 หรือช่วงที่สรุปแล้วอยู่แล้ว อย่าเพิ่มรายการที่แคบกว่าข้าง ๆ เพราะตัวเลือกที่ทับซ้อนจะติดตั้งpolicyที่แข่งขันกันและลำดับการประเมินเป็นตัวตัดสินผู้ชนะ
IKEv1 ทำให้แต่ละคู่ซับเน็ตเป็น Phase 2 ของตัวเอง และฝั่งที่รับคู่เดียวต่อการแลกเปลี่ยนจะทิ้งที่เหลือ IKEv2 พาได้หลายคู่ตัวเลือกในลูกเดียว แต่เฉพาะเมื่อทั้งสองImplementationยอมรับ รายการจาก swanctl --list-sas คือความจริง สิ่งที่คุณพิมพ์คือคำขอ
แบบใช้เส้นทาง: เส้นทางคือpolicy
อินเทอร์เฟซ XFRM หรืออุปกรณ์ VTI พาทราฟฟิกตามตารางเส้นทาง คุณชี้คำนำหน้าใหม่ไปที่อุปกรณ์ทั้งสองไซต์ และสถานะที่ผูกกับการแปลงของอินเทอร์เฟซก็ถูกใช้ ไม่มีคู่ตัวเลือกให้ซิงก์ ดังนั้นดีไซน์นี้จึงขยายได้ดีกว่าเมื่อซับเน็ตเพิ่มขึ้น คู่มือการส่งต่อของ strongSwan อธิบายฝั่งเคอร์เนลอย่างละเอียด
ip route add 192.168.60.0/24 dev xfrm0
ip route get 192.168.60.10WireGuard ไปไกลกว่านั้น AllowedIPs เป็นทั้งรายการอนุญาตเชิงคริปโตและผ่าน wg-quick เป็นรายการในตารางเส้นทาง ใส่คำนำหน้าเพียงฝั่งเดียวคุณจะได้แฮนด์เชก แพ็กเก็ตขาออก และความเงียบ เพราะฝั่งไกลทิ้งแพ็กเก็ตที่ต้นทางไม่อยู่ในรายการ รูปแบบ wg set แทนที่ทั้งรายการ ดังนั้นระบุคำนำหน้าที่เคยทำงานซ้ำ ไม่อย่างนั้นคุณจะตัดมันออก:
wg set wg0 peer <PUBKEY> allowed-ips 192.168.10.0/24,192.168.60.0/24
ip route add 192.168.60.0/24 dev wg0คำสั่งที่สองไม่ใช่ตัวเลือกเมื่อคุณใช้ wg set แทน wg-quick เคอร์เนลยอมรับรายการใหม่ทันที แต่ไม่มีอะไรเพิ่มเส้นทางให้ ดังนั้นทราฟฟิกที่สร้างในเครื่องยังออกผ่านเกตเวย์เริ่มต้นอยู่ เป็นสาเหตุที่พบบ่อยที่สุดที่ซับเน็ต WireGuard ใหม่ทำงานจากโฮสต์อุโมงค์ไม่ใช่จากแล็ปท็อป
เส้นทางขากลับล้มเหลวบ่อยกว่าอุโมงค์
โฮสต์ในซับเน็ตระยะไกลใหม่ต้องส่งคำตอบกลับผ่านเกตเวย์ VPN เมื่อเกตเวย์นั้นไม่ใช่เราเตอร์เริ่มต้นของพวกเขา คำตอบจะไปที่เราเตอร์ LAN ซึ่งทิ้งหรือส่งต่อไปอินเทอร์เน็ตด้วยที่อยู่ต้นทางส่วนตัว ทดสอบจากโฮสต์ฝั่งไกล ไม่ใช่จากเกตเวย์: ip route get 10.30.20.15 บน Linux หรือ Find-NetRoute -RemoteIPAddress 10.30.20.15 ใน PowerShell แสดงฮอปถัดไปที่โฮสต์ใช้จริง ถ้าคำตอบไม่ใช่จุดสิ้นสุดของอุโมงค์ ให้เพิ่มเส้นทางคงที่สำหรับคำนำหน้าใหม่ที่นั่น
NAT ต้นทางที่ไซต์ซึ่งไม่มีเส้นทางขากลับเป็นทางเลือกที่ชอบด้วยกฎหมาย และเป็นวิธีที่การติดตั้ง hub-and-spoke หลายแห่งหลีกเลี่ยงการแตะทุกเซิร์ฟเวอร์ ใช้กับคำนำหน้าใหม่ที่เกตเวย์ฝั่งปลายทางด้วย:
iptables -t nat -A POSTROUTING -s 10.30.20.0/24 -d 192.168.60.0/24 -j MASQUERADEค่าใช้จ่ายเป็นของจริง บันทึกฝั่งไกลเลิกแสดงที่อยู่ต้นทางรายตัว และกฎไฟร์วอลล์ที่อิงซับเน็ตเดิมก็รวมเป็นกฎเดียวสำหรับเกตเวย์ เลือกสิ่งนั้นอย่างตั้งใจ ไม่ใช่เพราะขาดเส้นทาง
ไฟร์วอลล์เป็นอีกครึ่งของเส้นทางขากลับ อุปกรณ์ที่ใช้โซนไม่ขยายโซนของอินเทอร์เฟซอุโมงค์เดิมไปยังซับเน็ตใหม่อัตโนมัติ และกฎที่เขียนสำหรับคำนำหน้าเก่าจะไม่ตรงกัน เพิ่มซับเน็ตใหม่ในโซนหรือคู่กฎทั้งสองทิศทางก่อนโทษ IPsec
ตัดสินด้วยสามคำถาม แล้วตรวจสอบด้วยทราฟฟิก
เวอร์ชันสั้น: คอนฟิกของฝั่งระบุคำนำหน้าหรือไม่ (แบบใช้policy) หรือทราฟฟิกถูกส่งไปยังอินเทอร์เฟซ (แบบใช้เส้นทาง)? ทั้งสองปลายระบุคำนำหน้าใหม่หรือไม่? มีเส้นทางกลับจากซับเน็ตใหม่ไปยังช่วงต้นทางเดิมหรือไม่?
| Tunnel style | Where the prefix goes | What breaks if you skip it |
|---|---|---|
| Policy-based IPsec | Selector pair on both peers | Old subnets work, the new one fails with no clear error |
| Route-based XFRM or VTI | Route into the device on both sites | Packets routed but not transformed, or the state never matches |
| WireGuard | AllowedIPs on both peers plus a route | Handshake succeeds, replies are dropped |
| Overlapping supernet | Adjust the existing entry instead | A shadowed policy wins or loses by evaluation order |
การตรวจสอบคือจุดที่การเปลี่ยนแปลงส่วนใหญ่ถูกปิดเร็วเกินไป ping จากเกตเวย์พิสูจน์ได้น้อย เพราะเกตเวย์ส่งจากตัวเองและมักตรงกับpolicyที่ต่างจากโฮสต์ ping จากโฮสต์ในซับเน็ตใหม่ แล้วรันแอปที่ทำให้เกิดการเปลี่ยนแปลง และดูตัวนับไม่ใช่ไอคอนสถานะ
tcpdump -ni any host 192.168.60.10 and (esp or udp port 4500)
ip xfrm state
wg showในอุโมงค์แบบใช้policy ตัวนับของ ip xfrm state ควรเพิ่มขึ้นทั้งสองทิศทาง ตัวนับนิ่งหมายถึงแพ็กเก็ตถูกส่งเส้นทางแต่ไม่ถูกเลือก ใน WireGuard wg show รายงานการถ่ายโอนต่อฝั่ง และแฮนด์เชกที่ไม่มีไบต์รับเลยชี้ไปที่รายการของฝั่งไกลหรือเส้นทางขากลับของมัน
จบด้วยการบันทึกคำนำหน้า ตัวเลือกหรือเส้นทางของฝั่ง การตัดสินเรื่องเส้นทางขากลับ และรายการไฟร์วอลล์พร้อมส่วนที่เหลือของบัญชีอุโมงค์ แล้วรีบูตเกตเวย์หนึ่งตัวและทดสอบอีกครั้ง เส้นทางที่เพิ่มด้วยมือจะหายไป และคนถัดไปไม่ควรต้องค้นพบมันใหม่