IP แบบคงที่ใน Azure P2S VPN: ทำไมที่อยู่ของไคลเอนต์จึงเปลี่ยน
Azure point-to-site แจกที่อยู่ว่างถัดไปจากพูลในทุกการเชื่อมต่อ จึงไม่มี IP คงที่ของไคลเอนต์ ใช้การควบคุมการเข้าถึงตามช่วงหรือตามตัวตนแทน
ไคลเอนต์ Azure point-to-site ทุกตัวได้รับที่อยู่จากพูลเมื่อยืนยันตัวตน และเก็บไว้เพียงตลอดอายุของการเชื่อมต่อนั้น ไม่มีตารางจอง ไม่มีการแมปตามผู้ใช้ และไม่มีการตั้งค่าเกตเวย์ที่หมายความว่า „ให้ที่อยู่ 172.16.0.10 กับคนนี้เสมอ“ กลไกเดียวนี้เองที่อธิบายอาการทั้งสองอย่างที่ผู้คนพบในภายหลัง คือกฎ NSG ที่เลิกตรงกับผู้ใช้ที่เคยตรง และรายการอนุญาตที่เปิดทางให้เครื่องที่ไม่มีใครตั้งใจเพิ่มเข้ามาอย่างเงียบ ๆ การแทนที่กฎด้วยกฎ IP ที่ฉลาดกว่าไม่ได้แก้ทั้งสองอย่าง เพราะสิ่งที่กฎระบุชื่อถูกจัดสรรใหม่ตามตารางเวลาที่คุณไม่ได้ควบคุม
พูลคือความจุ ไม่ใช่ตัวตน มันมีอยู่เพื่อให้อุโมงค์ที่ทำงานพร้อมกันได้ที่อยู่ที่ไม่ซ้ำ และนำกลับมาใช้ใหม่ในทันทีที่สัญญาเช่าสิ้นสุด เมื่อเข้าใจเรื่องนี้ คำถามที่มีประโยชน์ก็ไม่ใช่ „ฉันจะตรึงไคลเอนต์นี้อย่างไร“ อีกต่อไป แต่เป็น „ฉันจะเขียนกฎกับอะไรที่เกตเวย์จะไม่นำกลับมาใช้ใหม่“
เกตเวย์ทำอะไรจริง ๆ เมื่อไคลเอนต์เชื่อมต่อ
เกตเวย์เก็บพูลที่อยู่ไคลเอนต์ที่กำหนดค่าไว้และปฏิบัติต่อมันเหมือนตารางสัญญาเช่า เมื่อเชื่อมต่อจะเอาที่อยู่ว่างถัดไป ซึ่งในทางปฏิบัติคือที่อยู่ต่ำสุดที่ใช้ได้ และกำหนดให้อะแดปเตอร์อุโมงค์จนกว่าไคลเอนต์จะตัดการเชื่อมต่อหรือสัญญาเช่าหมดอายุ ลำดับเป็นตัวตัดสิน ไม่ใช่ตัวตน ใครก็ตามที่เชื่อมต่อใหม่เป็นคนแรกหลังช่วงเงียบจะได้ที่อยู่ต่ำสุดที่บังเอิญว่างอยู่ในขณะนั้น
ขนาดของพูลซ่อนพฤติกรรมไว้ พูลห้องแล็บที่ใหญ่กว่าจำนวนผู้ทดสอบหนึ่งหรือสองที่อยู่ดูเหมือนแน่นอน เพราะแล็ปท็อปเครื่องเดิมมักเชื่อมต่อใหม่ตามลำดับเดิมทุกเช้า เพิ่มเครื่องที่สาม เปลี่ยนขนาดพูล หรือปล่อยให้เซสชันเชื่อมต่อค้างไว้ช่วงมื้อกลางวัน รูปแบบก็แตก ที่อยู่ไม่เคยคงที่ คิวต่างหากที่คงที่
การเปลี่ยนแปลงใด ๆ ในการกำหนดค่า point-to-site ก็รีเซ็ตพื้นที่สัญญาเช่าด้วย ประเภทการยืนยันตัวตนที่ต่างออกไป พูลที่เปลี่ยนขนาด ช่วงพูลใหม่ หรือเกตเวย์ที่ถูกรื้อและสร้างใหม่ ล้วนส่งไคลเอนต์กลับไปยังพูลที่ไม่ตรงกับที่อยู่เดิมของพวกเขาอีกต่อไป ไม่มีส่วนใดของการเปลี่ยนแปลงนั้นแตะ NSG ของคุณ นี่คือเหตุผลที่ความเสียหายดูเหมือนเกิดขึ้นเอง
คุณดูมันเกิดขึ้นได้ในประมาณหนึ่งนาที เชื่อมต่อ บันทึกที่อยู่ของอุโมงค์ในรายละเอียดการเชื่อมต่อของไคลเอนต์ ตัดการเชื่อมต่อ เชื่อมต่อเครื่องที่สอง แล้วเชื่อมต่อเครื่องแรกอีกครั้ง ที่อยู่ที่ได้กลับมาขึ้นอยู่กับสิ่งที่เครื่องที่สองถืออยู่ และไม่มีการตั้งค่าพอร์ทัลใดที่จะคืนที่อยู่ก่อนหน้าให้ตามคำขอ
NSG ที่อิงกับ IP ของไคลเอนต์แท้จริงแล้วคือกฎเกี่ยวกับลำดับการเชื่อมต่อ
กฎที่ผู้คนเขียนเป็นข้อแรกคือข้อที่เห็นได้ชัด คือกฎขาเข้าบน NIC ของ VM สำหรับการจัดการหรือบนซับเน็ตของมัน โดยมีที่อยู่ภายในของไคลเอนต์ VPN เป็นต้นทาง มันสั้น ผ่านการทดสอบในวันที่เขียน และล้มเหลวทันทีที่พูลมีที่อยู่ว่างมากกว่าหนึ่งที่อยู่
จากตรงนั้นเกิดรูปแบบความล้มเหลวสองแบบ และมีเพียงแบบเดียวที่ดูเหมือนบั๊ก ผู้ใช้ที่ชอบด้วยกฎหมายถูกปฏิเสธเพราะคนอื่นกำลังถือที่อยู่ที่กฎระบุชื่ออยู่ในขณะนั้น และสิ่งนั้นมาในรูปตั๋วสนับสนุนที่น่ารำคาญ หรือผู้ใช้ที่ไม่ตั้งใจได้รับอนุญาตเพราะสืบทอดที่อยู่ที่กฎยังไว้ใจอยู่ และสิ่งนั้นไม่มาในรูปใดเลยจนกว่าจะมีใครตรวจสอบการเข้าถึง
เนื่องจากกฎตามสัญญาเช่า นโยบายที่ใช้จริงจึงอ่านว่า „คนแรกที่เชื่อมต่อได้รับการเข้าถึงสำหรับการจัดการ“ นี่คือคำอธิบายลำดับการเชื่อมต่อที่แต่งตัวเป็นเจตนา และไม่มีความสะอาดของกฎใดทำให้มันเป็นการแสดงเจตนา
สัญญาเช่าของไคลเอนต์และที่อยู่ของเกตเวย์เป็นวัตถุที่ต่างกัน
ความสับสนส่วนใหญ่มาจากคำเดียว เกตเวย์มี IP สาธารณะที่ค่อนข้างคงที่ ไคลเอนต์มีที่อยู่ส่วนตัวจากพูลซึ่งไม่คงที่ สำหรับเกตเวย์ VPN ที่ไม่มีความซ้ำซ้อนระดับโซน IP สาธารณะถูกจัดสรรแบบไดนามิก แต่ก็อยู่รอดจากการเปลี่ยนขนาด การรีเซ็ต และการบำรุงรักษาตามปกติ มันเปลี่ยนเมื่อเกตเวย์เองถูกลบและสร้างใหม่ SKU ของเกตเวย์แบบซ้ำซ้อนระดับโซนและแบบโซนใช้ IP สาธารณะระดับ Standard SKU และการจัดสรรนั้นต้องเป็นแบบคงที่
ความคงที่นั้นคือสิ่งที่เพียร์ในองค์กรต้องการในการกำหนดค่าของตน และไม่ได้บอกอะไรเกี่ยวกับการระบุไคลเอนต์แต่ละราย เมื่อพาร์ทเนอร์ถามว่าจะเห็นที่อยู่ใด คำตอบคือ IP สาธารณะของเกตเวย์ภายใต้ site-to-site หรือช่วง NAT ที่ใช้ร่วมกัน ไม่ใช่สัญญาเช่าอุโมงค์ของแล็ปท็อปเลย
พูลแบบกลุ่มให้ช่วงที่คุ้มค่ากับการเขียนกฎ
Virtual WAN point-to-site รองรับกลุ่มผู้ใช้ และแต่ละกลุ่มสามารถกำหนดพูลที่อยู่ไคลเอนต์ของตนเองได้ การเป็นสมาชิกตัดสินด้วยตัวตน ช่วงที่ไคลเอนต์ไปอยู่จึงคาดเดาได้ คือปฏิบัติการอยู่ในช่วงหนึ่ง ผู้รับเหมาอยู่อีกช่วงหนึ่ง และช่วงคือสิ่งที่กฎไฟร์วอลล์หรือ NSG ระบุชื่อได้โดยไม่ต้องเดา
ชุดกฎที่ได้จึงมีรูปร่างที่ตรวจทานได้
- หนึ่งพูลต่อกลุ่มเป้าหมาย ขนาดตามจุดสูงสุดของเซสชันพร้อมกัน ไม่ใช่จำนวนคน
- การเป็นสมาชิกกลุ่มจัดการผ่านตัวตน ไม่ใช่การแก้ไขกฎทุกครั้งที่มีคนเข้าร่วม
- กฎ NSG หรือ Azure Firewall เขียนกับช่วงของพูล ไม่ใช่กับสัญญาเช่าแต่ละราย
- ฮับหรือเกตเวย์แยกสำหรับกลุ่มเป้าหมายที่ต้องไม่แชร์ช่วงกันเลย
| Rule target | Survives a reconnect | What it still cannot express |
|---|---|---|
| Client tunnel address | No | Follows connection order and admits whoever holds the address next |
| Whole client pool | Yes | Grants every connected client identical access |
| Virtual WAN group pool | Yes | Only as reliable as group membership |
| Gateway public IP | Until the gateway is recreated | Identifies the site, not the person |
การใส่พูลทั้งพูลลงในรายการอนุญาตนั้นตรงไปตรงมาแต่หยาบ ทุกไคลเอนต์ที่เชื่อมต่อในช่วงนั้นได้การเข้าถึงเดียวกัน นั่นคือการตัดสินใจเชิงนโยบายที่ควรพูดออกมาดัง ๆ แทนที่จะไปค้นพบระหว่างการตรวจทาน สิ่งใดที่ยังต้องการคำตอบรายบุคคลเป็นของทรัพยากรผ่านการกำหนดบทบาท ไม่ใช่ของตัวกรองแพ็กเก็ต
เมื่อการปรับใช้ไม่สามารถย้ายไปยัง Virtual WAN ได้
เกตเวย์จำนวนมากยังคงเป็นเกตเวย์ VPN ธรรมดา และการย้ายไปยัง Virtual WAN ไม่ใช่การเปลี่ยนแปลงเล็กน้อย คำตอบในทางปฏิบัติคือย้ายการตัดสินใจรายผู้ใช้ออกจากตัวกรองแพ็กเก็ตไปยังสิ่งที่รู้อยู่แล้วว่าผู้ใช้คือใคร
ตัวตนระดับทรัพยากรเป็นเวอร์ชันที่ถูกที่สุด Storage, SQL และ Key Vault ทั้งหมดรองรับการยืนยันตัวตนของ Entra ID พร้อมการกำหนดบทบาทรายผู้ใช้หรือรายกลุ่ม VPN จึงต้องพิสูจน์เพียงการเข้าถึงเครือข่ายเท่านั้น โฮสต์กระโดดที่มีบัญชีระบุชื่อทำงานเดียวกันสำหรับงานบริหาร เพราะโฮสต์บันทึกคนและอุโมงค์เพียงขนแพ็กเก็ต การลงทะเบียนไคลเอนต์ใน DNS และอนุญาตชื่อแทนหมายเลขจะยกกฎขึ้นหนึ่งชั้น ตัวตนระดับแอปพลิเคชัน เช่น หัวข้อใบรับรอง การอ้างสิทธิ์ของโทเค็น การเป็นสมาชิกกลุ่ม ทำงานเมื่อสิ่งที่ถูกขอให้ตัดสินคือแอปพลิเคชัน ไม่ใช่เครือข่าย
สำหรับพาร์ทเนอร์ที่ยืนกรานให้มีที่อยู่ต้นทางคงที่ คำตอบคือ site-to-site หรือ ExpressRoute ที่มีคำนำหน้าเพียร์ที่กำหนดไว้ พวกเขาอนุญาตคำนำหน้าเพียร์ ที่อยู่ที่ปรากฏฝั่งของพวกเขาเป็นของเกตเวย์ และจะไม่เปลี่ยนเมื่อมีคนรีสตาร์ตแล็ปท็อป
ตรวจสอบพูลก่อนแก้ไขรายการอนุญาตอื่น
คุณสมบัติสองอย่างของพูลทำให้เกิดพฤติกรรมส่วนใหญ่ที่ผู้คนโทษไคลเอนต์ พูลที่เล็กเกินไปนำสัญญาเช่ากลับมาใช้เร็ว ที่อยู่จึงดูเหมือนเคลื่อนที่ตลอดเวลา และกฎใดที่อิงกับที่อยู่ก็ดูไม่น่าเชื่อถือตั้งแต่การออกแบบ พูลที่ทับซ้อนกับช่วงในองค์กรหรือพื้นที่ที่อยู่ของเครือข่ายเสมือนทำให้เกิดความกำกวมในการกำหนดเส้นทางที่กฎไฟร์วอลล์ใดก็แก้ไม่ได้
วางสามสิ่งบนหน้าเดียว ก่อนแตะกฎ คือพูล point-to-site พื้นที่ที่อยู่ของเครือข่ายเสมือน และช่วงในองค์กร สิ่งเหล่านี้ต้องไม่ทับซ้อนกัน และพูลต้องมีที่พอสำหรับไคลเอนต์พร้อมกันทุกตัวบวกส่วนเผื่อสำหรับการเชื่อมต่อใหม่
จากนั้นปิดวงในลำดับนี้
- เชื่อมต่อจากสองเครื่องในทั้งสองลำดับและเปรียบเทียบที่อยู่ หากสลับกันได้ ก็ไม่มีกฎที่อิงกับที่อยู่ใดปลอดภัย
- ตรวจสอบว่าเกตเวย์เป็น Virtual WAN หรือไม่ หากใช่ ให้ใช้พูลแบบกลุ่มแทนกฎรายที่อยู่
- ถามว่าเกิดอะไรขึ้นเมื่อกฎตรงกับคนผิด หากคำตอบคือเหตุการณ์ด้านการเข้าถึง ให้ย้ายการควบคุมไปที่ตัวตน
- บันทึกว่าช่วงใดเป็นของกลุ่มใดในที่เก็บเดียวกันกับนิยาม NSG
- ทดสอบซ้ำหลังการเปลี่ยนแปลงพูล การยืนยันตัวตน หรือเกตเวย์ทุกครั้ง เพราะการเปลี่ยนแปลงเหล่านั้นเขียนการแมปใหม่โดยไม่ประกาศ