Azure Web App เข้าถึงภายในองค์กรผ่าน VPN ได้อย่างไร

คำขอขาออกของ Web App ทำให้พนักงานที่คุณไม่เคยเห็นจากแหล่งที่คุณไม่ได้เลือก และไฟร์วอลล์สำนักงานจะต้องยอมรับคำขอดังกล่าว นั่นคือปัญหาทั้งหมดในประโยคเดียว การรวม VNet ระดับภูมิภาคจะทำให้คำขอมีเส้นทางเข้าสู่เครือข่ายเสมือน และ VPN แบบไซต์ต่อไซต์จะนำคำขอดังกล่าวจากที่นั่น ทุกอย่างที่ผิดพลาดหลังจากนั้นขึ้นอยู่กับช่วงต้นทางและเส้นทางที่แพ็กเก็ตใช้จริง

สิ่งที่พนักงานส่งจริงๆ

บริการแอปเรียกใช้โค้ดของคุณกับพนักงานที่อยู่นอกมุมมองเครือข่ายการสมัครของคุณ เมื่อเปิดใช้งานการบูรณาการระดับภูมิภาคการรับส่งข้อมูลขาออกจะถูกส่งไปยังเครือข่ายย่อยที่ได้รับมอบสิทธิ์ใน VNet ในภูมิภาคเดียวกัน และแพ็กเก็ตจะปรากฏขึ้นที่นั่นก่อนที่จะดำเนินการต่อ การรวมระบบจะไม่ย้ายแอปไปยัง VNet และไม่เปลี่ยนที่อยู่ขาเข้า มันทำให้โฟลว์ขาออกมีฮอปแรกที่แตกต่างออกไปเท่านั้น

ตามค่าเริ่มต้น เฉพาะพื้นที่ที่อยู่ส่วนตัวเท่านั้นที่ใช้เส้นทางนั้น ดังนั้นปลายทางอินเทอร์เน็ตทั่วไปจึงยังคงออกจากผู้ปฏิบัติงานโดยตรง การกำหนดเส้นทางทุกอย่างผ่าน VNet เป็นการตั้งค่าที่แยกจากกันและเป็นการตัดสินใจที่แยกจากกัน เพราะมันจะส่งการพึ่งพาสาธารณะของคุณข้ามอุโมงค์ด้วย

การรับส่งข้อมูลการกำหนดค่า เช่น การดึงอิมเมจคอนเทนเนอร์เมื่อเริ่มต้น เป็นไปตามกฎการกำหนดเส้นทางของตัวเอง และอาจล้มเหลวได้ในขณะที่การเรียก API ของคุณสำเร็จ

ซับเน็ตการรวมเป็นแหล่งที่มาที่คุณต้องอนุญาต

สำนักงานจะเห็นช่วงที่อยู่ของเครือข่ายย่อยการรวมหรืออะไรก็ตามที่อุปกรณ์ของคุณแปล ไม่ใช่ที่อยู่ขาออกสาธารณะของแอป ใส่ช่วงนั้นลงในตัวเลือกการรับส่งข้อมูลของ VPN ของไซต์ และในกฎไฟร์วอลล์ภายในองค์กร หากทันเนลเป็นไปตามนโยบายตัวเลือกที่ละเว้นจะทิ้งแพ็กเก็ตแม้ว่าจะมีเส้นทางอยู่ก็ตาม

ไม่อนุญาตให้มีที่อยู่ของพนักงานเพียงรายเดียวที่คุณบังเอิญสังเกตเห็น อินสแตนซ์เปลี่ยนแปลงไปตามการปรับขนาดและการบำรุงรักษาแพลตฟอร์ม และกฎที่ปักหมุดไว้ที่ที่อยู่เดียวจะพังในช่วงเวลาที่เลวร้ายที่สุด

ทำให้ด้านปลายทางแคบ: หนึ่งบริการ หนึ่งพอร์ต หนึ่งทิศทาง โดยอนุญาตให้ใช้เส้นทางกลับได้อย่างชัดเจน

การส่งต่อแบบเพียร์และเกตเวย์มีความชัดเจน

หากเกตเวย์ VPN อยู่ในฮับ VNet และซับเน็ตการรวมใน Spoke เส้นทางนั้นจำเป็นต้องได้รับอนุญาตในการส่งผ่านเกตเวย์บนการเพียร์ฮับ และการใช้เกตเวย์ระยะไกลที่เปิดใช้งานบนการเพียร์พูด การเพียร์โดยตัวมันเองจะนำการรับส่งข้อมูลระหว่าง VNet ทั้งสองและไม่มีอะไรเพิ่มเติม เส้นทางที่มีประสิทธิภาพบนซับเน็ตการรวมคือที่ที่คุณยืนยันว่าเกตเวย์ฮอปถัดไปอยู่ที่นั่นจริงๆ

การออกแบบแบบฮับและซี่ซึ่งมีตารางเส้นทางส่ง 0.0.0.0/0 ไปยังไฟร์วอลล์เป็นตัวแปรทั่วไป และไฟร์วอลล์นั้นจำเป็นต้องมีกฎของตัวเองสำหรับคำนำหน้าภายในองค์กร

วาดเส้นทางบนกระดาษก่อนเปิดตั๋วกับทีมเครือข่ายเพราะจะช่วยประหยัดเวลาในการคาดเดารวมทิศทางการกลับไว้ในภาพวาดเนื่องจากครึ่งหนึ่งของคนลืมไป

ปลายทางส่วนตัวขาเข้าเป็นอีกทิศทางหนึ่ง

ปลายทางส่วนตัวทำให้แอปสามารถเข้าถึงได้จากภายใน VNet มันไม่ได้ทำอะไรเลยสำหรับการโทรออกของแอปไปยังสำนักงาน และทีมก็กำหนดค่าการโทรเป็นประจำในขณะที่ข้อกำหนดที่แท้จริงกลับกัน

เอกสารเก่าอธิบายการบูรณาการที่ต้องใช้เกตเวย์ซึ่งสร้างขึ้นบน VPN แบบจุดต่อไซต์ ซึ่งเป็นคุณสมบัติที่แตกต่างที่มีข้อกำหนดของตัวเอง Microsoft กำหนดเวลาการยุติการให้บริการฟีเจอร์ดังกล่าวในวันที่ 31 มีนาคม 2027 และแนะนำให้บูรณาการในระดับภูมิภาคแทน

อย่าคัดลอกการกำหนดค่าแบบจุดต่อไซต์แบบเดิมเพียงเพราะมีตัวอย่างเก่าใช้

ยืนยันด้วยบริบทของแอปเอง

ทดสอบจากแอปที่ใช้งาน ไม่ใช่จากแล็ปท็อปของคุณและไม่ใช่จาก VM ใน VNet เดียวกัน บันทึกที่อยู่ที่ได้รับการแก้ปัญหา ผลการเชื่อมต่อ และการตอบสนองระดับแอปพลิเคชันแยกกัน เนื่องจาก DNS ล้มเหลว การหมดเวลาของ TCP และจุดปฏิเสธการตรวจสอบสิทธิ์ที่เจ้าของที่แตกต่างกันสามคน หากการจำแนกชื่อล้มเหลว ให้แก้ไข DNS ส่วนตัวสำหรับ VNet ก่อนที่จะแตะอุโมงค์

สถานะอุโมงค์สีเขียวเป็นเพียงการพิสูจน์ว่าเกตเวย์พร้อมใช้งานแล้ว มันไม่ได้พูดอะไรเกี่ยวกับตัวเลือก กฎไฟร์วอลล์ หรือ DNS

เมื่อคำขอใช้งานได้ในที่สุด ให้เขียนช่วงต้นทาง พอร์ตปลายทาง และโซน DNS ลงใน Runbook ของแอป บุคคลถัดไปที่จะแก้ไขข้อบกพร่องนี้จะเริ่มจากบันทึกของคุณ แทนที่จะเริ่มจากหน้าสถานะของเกตเวย์