ทำไม Azure Point-to-Site VPN จึงไม่เปลี่ยน IP สาธารณะของคุณ
อุโมงค์แบบจุดไปยังไซต์พาเฉพาะเส้นทางของเครือข่ายเสมือนเท่านั้น IP สาธารณะของคุณจึงยังคงเป็นแบบโลคอลจนกว่าการทำอุโมงค์แบบบังคับและ SNAT ของไฟร์วอลล์จะย้ายทางออกไปยัง Azure
ผมเชื่อมต่อไคลเอนต์ Azure VPN บนแล็ปท็อป Windows เปิดหน้าที่สะท้อนที่อยู่ และเห็นที่อยู่สาธารณะเดียวกันกับที่เราเตอร์ที่บ้านแจกไป ระหว่างนั้นกล่องกระโดดที่ 10.20.0.4 ตอบสนองและชื่อปลายทางส่วนตัวก็ถูกแปลงได้ แปลว่าอุโมงค์ไม่ได้เสียหาย เกตเวย์แบบจุดไปยังไซต์ทำตามที่การกำหนดค่าเริ่มต้นบอกไว้ทุกประการ คือพาคำนำหน้าส่วนตัวไปและปล่อยทุกอย่างที่เหลือไว้บนลิงก์โลคอล การได้ที่อยู่ทางออกที่เป็นของ Azure คือการเปลี่ยนการออกแบบเส้นทาง ไม่ใช่การซ่อม
เกตเวย์ประกาศอะไรเป็นค่าเริ่มต้น
เกตเวย์ดันเส้นทางสำหรับพื้นที่ที่อยู่ของเครือข่ายเสมือน รวมถึงเครือข่ายเพียร์ที่อนุญาตให้ส่งผ่านเกตเวย์ และคำนำหน้าภายในที่เรียนรู้ผ่านการเชื่อมต่อแบบไซต์ถึงไซต์หรือ BGP ในชุดนั้นไม่มี 0.0.0.0/0 ระบบปฏิบัติการของคุณเก็บเส้นทางเริ่มต้นไว้บน Wi-Fi หรือ Ethernet แพ็กเก็ตที่ไปยัง API สาธารณะจึงไม่เคยเข้าอุโมงค์ตั้งแต่แรก
ที่อยู่ที่ไคลเอนต์ได้รับในอุโมงค์คือสัญญาเช่าส่วนตัวจากพูลแบบจุดไปยังไซต์ มันระบุตัวไคลเอนต์ต่อทรัพยากรใน VNet ไม่ใช่ที่อยู่ที่อินเทอร์เน็ตมองเห็นได้ และจะไม่ปรากฏเป็นต้นทางของคำขอขาออกไปยัง API ของ SaaS เลย รายการในรายการที่อนุญาตซึ่งสร้างจากสัญญาเช่านั้นใช้ไม่ได้ ไม่ว่าคุณจะรอนานแค่ไหนให้มันปรากฏในบันทึกของผู้ให้บริการ
อุโมงค์แบบแบ่งกับการทำอุโมงค์แบบบังคับเคียงกัน
| Split tunnel, the default | Forced tunneling | |
|---|---|---|
| Internet traffic exits through | local ISP or office router | firewall or appliance inside Azure |
| Source address the API sees | your home or office IP | the firewall public IP |
| Inspection and logging in Azure | none | policy rules plus flow logs |
| Ongoing cost | gateway only | gateway, firewall hours, data processing |
| What usually breaks | nothing on the egress path | DNS, on-premises routes, overlapping local ranges |
มีเพียงแถวที่สองที่เปลี่ยนที่อยู่ซึ่งบริการระยะไกลมองเห็น ทุกอย่างอื่นในตารางนั้นคือต้นทุนและพื้นผิวการดำเนินงานที่คุณยอมรับเมื่อต้องตรวจสอบหรือแปลทางออกภายใน Azure ถ้ามีคนขอให้คุณทำให้ IP สาธารณะเปลี่ยน เขากำลังขอทั้งคอลัมน์ขวา ไม่ใช่การปรับเล็กน้อยที่ไคลเอนต์
มีทางเลือกตรงกลางที่ควรเอ่ยถึงก่อนจะสร้างอะไรใหม่ VM ที่ทำหน้าที่พร็อกซีหรือเกตเวย์ใน VNet ให้ที่อยู่ต้นทางที่ควบคุมได้สำหรับแอปพลิเคชันที่ชี้ไปที่มันได้ โดยไม่ต้องย้ายเส้นทางเริ่มต้นของไคลเอนต์ วิธีนี้ทำให้การท่องเว็บปกติยังอยู่ภายในและยังตอบโจทย์พาร์ตเนอร์ที่ต้องการเพียงการเรียก API หนึ่งครั้งมาจาก Azure แต่จะล้มเหลวเมื่อความต้องการเป็นเรื่องของทราฟฟิกทั้งหมดจริง ๆ เพราะอะไรก็ตามที่ไม่สนใจการตั้งค่าพร็อกซียังคงออกทางโลคอล
ทำให้อุโมงค์พาเส้นทางเริ่มต้น
บนเกตเวย์เครือข่ายเสมือน วิธีที่รองรับในการบังคับทราฟฟิกอินเทอร์เน็ตทั้งหมดของไคลเอนต์เข้าอุโมงค์คือเพิ่มเส้นทางที่กำหนดเองในการกำหนดค่าแบบจุดไปยังไซต์ สองครึ่งครอบคลุมพื้นที่ IPv4 ทั้งหมด และแต่ละอันเจาะจงกว่าเส้นทางเริ่มต้นภายใน ไคลเอนต์จึงเลือกใช้โดยไม่ต้องลบอะไร:
Set-AzVirtualNetworkGateway -VirtualNetworkGateway GWOBJ -CustomRoute 0.0.0.0/1,128.0.0.0/1บรรทัดนั้นเป็นตัวอย่าง ไม่ใช่ชุดที่คัดลอกได้ทั้งดุ้น: ดึงอ็อบเจกต์เกตเวย์ด้วย Get-AzVirtualNetworkGateway แล้วแทนที่ GWOBJ ด้วยมัน และยืนยันก่อนรันว่า SKU และรูปแบบการปรับใช้ยอมรับเส้นทางที่กำหนดเอง เดียวกันนั้นปรากฏในพอร์ทัลบนหน้าการกำหนดค่าแบบจุดไปยังไซต์ ซึ่งเป็นที่ที่ปลอดภัยกว่าในการตั้งค่าหากคุณยังไม่เขียนสคริปต์จัดการเกตเวย์
การเปลี่ยนคำนำหน้าเหล่านั้นทำให้แพ็กเกจไคลเอนต์ใช้ไม่ได้ ดาวน์โหลดแพ็กเกจไคลเอนต์ VPN ใหม่แล้วติดตั้งซ้ำ เพราะเส้นทางเดินทางอยู่ภายในโปรไฟล์ ไคลเอนต์ที่เชื่อมต่อใหม่ด้วยโปรไฟล์เก่าจะยังคงชุดเส้นทางเดิม และคุณอาจเสียเวลาหนึ่งชั่วโมงกับการแก้ปัญหาการเปลี่ยนแปลงที่ไม่เคยไปถึงมัน
ในฮับ Virtual WAN ที่ปลอดภัย สิ่งที่เทียบเท่าคือเส้นทางเริ่มต้นในตารางเส้นทางของฮับที่เชื่อมกับเกตเวย์แบบจุดไปยังไซต์ โดยมี Azure Firewall ในฮับรับทราฟฟิกไป ไฟร์วอลล์แปลการเชื่อมต่อที่มุ่งสู่อินเทอร์เน็ตเป็นที่อยู่ IP สาธารณะของตัวเอง และที่อยู่ทางออกใหม่ก็มาจากการแปลนั้น เมื่อไฟร์วอลล์มี IP สาธารณะหลายตัว ตัวใดตัวหนึ่งก็สามารถปรากฏเป็นต้นทางได้ รายการที่อนุญาตจึงต้องมีทั้งหมด
ทั้งสองแบบข้างต้นเป็น IPv4 คำนำหน้า /1 สองรายการไม่ได้ทำอะไรให้ IPv6 และการรองรับ IPv6 ของแบบจุดไปยังไซต์แคบพอที่คุณควรทดสอบการผสมก่อนสัญญาว่าเท่ากัน
ตรวจเส้นทาง แล้วตรวจทางออก
หลังติดตั้งแพ็กเกจใหม่และเชื่อมต่ออีกครั้ง ยืนยันว่าไคลเอนต์ติดตั้งสองครึ่งจริง บน Windows Get-NetRoute -DestinationPrefix 0.0.0.0/1 และคำสั่งเดียวกันสำหรับ 128.0.0.0/1 ควรระบุอินเทอร์เฟซของอุโมงค์ และ route print แสดงทั้งสองข้างเส้นทางเริ่มต้นเดิมของคุณ บน Linux ip route show ต้องแสดงคำนำหน้าทั้งสอง หากไม่แสดง โปรไฟล์ก็ไม่เคยพามันมา
จากนั้นตรวจที่อยู่สาธารณะจากไคลเอนต์อีกครั้งและอ่านบันทึกไฟร์วอลล์สำหรับการเชื่อมต่อเดียวกัน ต้นทางควรเป็น IP สาธารณะของไฟร์วอลล์พร้อมพอร์ตที่ถูกแปล ไคลเอนต์ที่ยังออกทางโลคอลทั้งที่มีเส้นทางทั้งสองอยู่ แปลว่าแพ็กเก็ตไปถึง Azure แล้วออกไปอีกทางหนึ่ง คือเส้นทางที่ผู้ใช้กำหนดบนซับเน็ตของเกตเวย์ ไฟร์วอลล์ที่ถูกบังคับให้ทำอุโมงค์ไปยังเครือข่ายภายในเอง หรือนโยบายที่ทิ้งโฟลว์ก่อนการแปล
ทดสอบปลายทางส่วนตัวหนึ่งแห่งซ้ำในเซสชันเดียวกัน โฮสต์กระโดดที่หยุดตอบสนองหลังการเปลี่ยนแปลง เป็นสัญญาณปกติว่าคำนำหน้าใหม่ไปแทนที่อะไรบางอย่าง ไม่ว่าเส้นทางภายในที่แคบกว่าซึ่งเคยประกาศไว้ หรือการแปลงชื่อที่ตอนนี้ไปยังตัวแก้ชื่อที่ไม่มีตัวส่งต่อสำหรับโซนส่วนตัวของคุณ
เมื่อใดควรปล่อยอุโมงค์แบบแบ่งไว้
ถ้าเป้าหมายเป็นเพียงการเข้าถึง API ส่วนตัว ปลายทางส่วนตัว หรือหน้าผู้ดูแลภายใน พฤติกรรมเริ่มต้นนั้นถูกกว่าและเงียบกว่า การทำอุโมงค์แบบบังคับเพิ่มชั่วโมงไฟร์วอลล์และค่าประมวลผลข้อมูล เส้นทางที่ยาวขึ้น และอีกจุดที่ทุกโฟลว์ของไคลเอนต์ล้มเหลวได้ มันยังดักจับทราฟฟิกมากกว่าปลายทางเดียวที่คุณใส่ใจมาก
ใช้มันเมื่อความต้องการระบุในแง่ของทางออก พาร์ตเนอร์ต้องเห็นที่อยู่ Azure ที่คงที่ ฝ่ายความปลอดภัยต้องการให้บันทึกและตรวจสอบการเชื่อมต่อ หรือข้อมูลต้องออกผ่านจุดควบคุมจุดเดียว แม้ตอนนั้นการออกแบบก็ให้ทางออกร่วมกับทุกผู้ใช้ ความรับผิดชอบรายผู้ใช้จึงต้องมาจากตัวตนในแอปพลิเคชัน ไม่ใช่จากที่อยู่ต้นทาง
ก่อนปิดการเปลี่ยนแปลง ยืนยันสี่อย่าง: แพ็กเกจไคลเอนต์ที่ติดตั้งเป็นตัวใหม่ เส้นทาง /1 สองเส้นอยู่บนอินเทอร์เฟซของอุโมงค์ ปลายทางส่วนตัวยังตอบสนอง และบันทึกของบริการระยะไกลแสดงที่อยู่ไฟร์วอลล์