เข้าถึงแอป Container Apps ส่วนตัวผ่าน VPN แบบจุดไปไซต์
สภาพแวดล้อม Container Apps ภายในต้องการทางเข้าส่วนตัว ชื่อโฮสต์ที่ตรงกัน และตัวแก้ชื่อที่ VPN เข้าถึงได้ รันทุกขั้นตอน จากนั้นตรวจสอบการปฏิเสธ
คู่มือนี้ครอบคลุมสภาพแวดล้อม Container Apps ที่มีโปรไฟล์เวิร์กโหลดและทางเข้าของเครือข่ายเสมือนภายใน ซึ่งเข้าถึงได้จากแล็ปท็อปผ่าน VPN แบบจุดไปไซต์ที่ได้รับอนุมัติ โดยใช้ FQDN โดยตรงของแอปและไม่มีเส้นทาง HTTP ระดับสภาพแวดล้อม ทางเข้าของสภาพแวดล้อมเข้าถึงได้จากไคลเอนต์, ขอบเขตอินเกรสของแอปยอมรับผู้เรียก และชื่อโฮสต์แก้เป็นทางเข้าส่วนตัว ทุกขั้นตอนด้านล่างทิ้งผลลัพธ์ที่ตรวจสอบได้และการย้อนกลับที่ไม่แตะต้องสิ่งใดที่คุณไม่ได้เปลี่ยนแปลง ทำตามลำดับที่กำหนด เพราะไม่มีขั้นตอนใดในภายหลังจะชดเชยการตัดสินใจเรื่องขอบเขตที่ทำผิดในขั้นตอนที่ 1 ได้
ก่อนแตะ DNS ให้ชี้แจงคำว่าภายใน คำนี้ใช้กับสองขอบเขตที่แตกต่างกันในผลิตภัณฑ์นี้ และการสลับกันเป็นสาเหตุที่พบบ่อยที่สุดที่ชื่อที่ใช้งานได้ยังคงไม่ส่งคืนสิ่งที่มีประโยชน์
ขั้นตอนที่ 1: กำหนดขอบเขตของสภาพแวดล้อมและแอป
อ่านการกำหนดค่าอินเกรสของแอปก่อนเปลี่ยนระเบียนใด ๆ:
| Setting | Boundary |
|---|---|
| Internal environment | The environment entry is reached through its private network arrangement |
| App with internal ingress | Callers from the environment VNet only; a VPN laptop qualifies once it has a route into that VNet and the domain resolves privately |
| App with external ingress in an internal environment | The app accepts outside traffic through the environment's private entry |
อินเกรสภายในถูกเปิดเผยบนโหลดบาลานเซอร์ภายในของสภาพแวดล้อมภายใน VNet ของสภาพแวดล้อม ดังนั้นคำถามไม่ใช่ว่าแล็ปท็อปเป็นแอปคอนเทนเนอร์อื่นหรือไม่ แต่คือมันเข้าถึง VNet นั้นได้หรือไม่ ไคลเอนต์ VPN ที่มีเส้นทางเข้า VNet และโดเมนเริ่มต้นของสภาพแวดล้อมที่แก้ผ่านโซนส่วนตัวถือเป็นผู้เรียกที่มีสิทธิ์ และนั่นคือสิ่งที่ขั้นตอนที่เหลือสร้างขึ้น สภาพแวดล้อมภายในที่ไม่มีทางเข้าสาธารณะเป็นข้อเท็จจริงที่ต่างจากแอปที่มีอินเกรสภายใน และอินเกรสภายนอกระดับแอปไม่ได้ให้ประตูสาธารณะแก่สภาพแวดล้อม เขียนขอบเขตลงในตั๋วและพอร์ทัลด้วย เพราะวิศวกรคนถัดไปอ่านตั๋วก่อน
ยืนยันขอบเขตนั้นกับเจ้าของการกำหนดค่าก่อนดำเนินการต่อ และรักษาประตูให้แคบ: หากไม่มีเส้นทางเข้า VNet ของสภาพแวดล้อม หรือโดเมนเริ่มต้นของสภาพแวดล้อมไม่แก้ผ่านโซนส่วนตัว ให้หยุดและแก้เส้นทางนั้นก่อน ไม่มีขั้นตอนใดในภายหลังจะแทนที่ผู้เรียกที่ไม่สามารถเข้าถึง VNet หรือแก้ชื่อได้
ขั้นตอนที่ 2: เก็บชื่อโฮสต์จริงและที่อยู่ทางเข้า
บันทึกโดเมนเริ่มต้นของสภาพแวดล้อม ที่อยู่ทางเข้าส่วนตัวแบบคงที่ และ FQDN ที่กำหนดค่าไว้ของแอป โดยนำมาจากทรัพยากรไม่ใช่ภาพหน้าจอเก่าหรือหน้าวิกิ:
az containerapp env show -n ENV -g RG \
--query "{domain:properties.defaultDomain, ip:properties.staticIp}"
az containerapp show -n APP -g RG \
--query "properties.configuration.ingress.fqdn"คำแนะนำ ทางเข้าส่วนตัวของ Container Apps อธิบายการจับคู่โดเมนของสภาพแวดล้อมกับที่อยู่ภายในโดยรักษาชื่อโฮสต์ของแอปพลิเคชันไว้ นี่คือรูปแบบที่คุณสร้างด้วยมือที่นี่ ดังนั้นจัดเนื้อหาของโซนให้สอดคล้องกับมันแทนที่จะคิดค้นรูปแบบการตั้งชื่อใหม่
หากโดเมนที่คุณอ่านไม่ตรงกับ FQDN ที่แอปรายงาน ให้หยุดและกระทบยอดทันที การสร้างโซนบนส่วนต่อท้ายที่ไม่ถูกต้องทำให้ได้ชื่อโฮสต์ที่แก้ได้อย่างสมบูรณ์และยังคงไปลงเอยที่โฮสต์เสมือนผิดตัว
ขั้นตอนที่ 3: วางโซนส่วนตัวบนเส้นทางตัวแก้ชื่อของ VPN
สร้างหรือใช้โซน DNS ส่วนตัวที่รองรับสำหรับโดเมนเริ่มต้นจริงของสภาพแวดล้อม โดยมีระเบียนไวลด์การ์ดและที่อยู่ตามเอกสารชี้ไปที่ทางเข้าคงที่ เชื่อมโยงโซนนั้นกับเครือข่ายเสมือนที่เหมาะสม และทำให้อำนาจส่วนตัวเข้าถึงได้ผ่านเส้นทางตัวแก้ชื่อที่ได้รับอนุมัติของ VPN แทนที่จะถือว่าการเชื่อมโยงเพียงพอ
ไคลเอนต์แบบจุดไปไซต์มักต้องมีปลายทางขาเข้าของตัวแก้ชื่อส่วนตัวหรือตัวส่งต่อ DNS ที่รองรับเพื่อเข้าถึงโซนนั้น การเชื่อมโยงโซนเปลี่ยนสิ่งที่ Azure แก้ให้กับเครือข่ายที่เชื่อมโยง ไม่ได้เปลี่ยนเส้นทางตัวแก้ชื่อสาธารณะของแล็ปท็อปภายนอกทุกเครื่อง อย่าแทนที่ด้วยโซน DNS ของปลายทางส่วนตัวที่ยืมมาจากรูปแบบเครือข่าย Container Apps อื่น เพราะชื่อระเบียนและส่วนต่อท้ายของโซนจะไม่ตรงกัน
การย้อนกลับสำหรับขั้นตอนนี้คือการลบการเชื่อมโยงโซนหรือระเบียนที่คุณเพิ่ม บันทึกว่าเป็นอย่างใดอย่างหนึ่ง เพราะการลบโซนที่ใช้ร่วมกันเพื่อย้อนการเชื่อมโยงเดียวเป็นวิธีที่รู้จักกันดีในการทำให้สภาพแวดล้อมที่สองเสียหาย
ขั้นตอนที่ 4: ทดสอบชื่อ จากนั้นทดสอบผู้ชมที่ถูกปฏิเสธ
ทดสอบชื่อโฮสต์และอัตลักษณ์ TLS ไปพร้อมกัน ไม่ใช่แค่ที่อยู่ สำหรับการวินิจฉัยการแมปชื่อแบบควบคุมคุณสามารถปักหมุดที่อยู่โดยคงชื่อโฮสต์ไว้:
curl --resolve app.ENVIRONMENT_DOMAIN:443:10.40.0.10 \
https://app.ENVIRONMENT_DOMAIN/แทนที่ชื่อโฮสต์ด้วย FQDN จริงของแอป และแทนที่ที่อยู่ด้วยทางเข้าภายในจริง สิ่งนี้มีผลกับคำขอเดียวนั้นและไม่ใช่การจัดเตรียม DNS อย่าเพิ่ม -k เพื่อเปลี่ยนความล้มเหลวของอัตลักษณ์ให้กลายเป็นการผ่านที่ดูเหมือนสำเร็จ เพราะการไม่ตรงกันของใบรับรองคือสัญญาณว่าคุณกำลังชนตัวรับฟังผิดตัว
การขอที่อยู่ตัวเลขโดยตรงอาจเลือกโฮสต์เสมือนผิดตัวหรือทำให้การตรวจสอบล้มเหลวแม้ในขณะที่ TCP 443 ตอบสนอง ดังนั้นให้ถือว่าการทดสอบ IP ที่สำเร็จเป็นหลักฐานเกี่ยวกับเครือข่ายและไม่มากไปกว่านั้น จากแล็ปท็อปที่ตั้งใจไว้ เส้นทางตัวแก้ชื่อปกติคือตัวส่งต่อ DNS ของไคลเอนต์หรือปลายทางขาเข้าของตัวแก้ชื่อส่วนตัวที่โฮสต์โซน และความล้มเหลวตรงนั้นคือปัญหาในการเข้าถึงตัวแก้ชื่อ ไม่ใช่ระเบียนที่หายไป ยืนยันว่าคำขอเดียวกันสำเร็จบนเส้นทางนั้น แล้วยืนยันว่าผู้ชมที่ถูกปฏิเสธยังคงถูกปฏิเสธ
สิ่งที่ต้องบันทึกและสิ่งที่ต้องย้อนกลับ
พอร์ตเป้าหมายของคอนเทนเนอร์และพอร์ต HTTPS ของไคลเอนต์เป็นการตั้งค่าแยกกัน อย่าเผยแพร่พอร์ตเป้าหมายของคอนเทนเนอร์ผ่าน VPN เพราะคอนเทนเนอร์ฟังอยู่ที่นั่น และอย่าขยายกฎเครือข่ายเพื่อให้การทดสอบพอร์ตผ่าน การเปลี่ยนแปลงทั้งสองอยู่รอดหลังเหตุการณ์และยากที่จะระบุที่มาภายหลัง
จบด้วยการดำเนินการแอปพลิเคชันใหม่จากแล็ปท็อปที่ตั้งใจไว้ โดยใช้อัตลักษณ์ที่ได้รับอนุญาตและ DNS ปกติ จากนั้นตรวจสอบว่าผู้เรียกที่ไม่ได้รับอนุญาตยังคงล้มเหลว ขณะที่คุณอยู่ในการกำหนดค่าแอป ให้ยืนยันด้วยว่าเส้นทาง HTTP ระดับสภาพแวดล้อมเปิดเผยแอปนี้เป็นเป้าหมายหรือไม่ เพราะเส้นทางนั้นเป็นประตูที่สองที่ขอบเขตอินเกรสไม่ได้อธิบาย
บันทึกค่าห้าค่าด้วยกัน: ขอบเขตสภาพแวดล้อม ขอบเขตอินเกรสของแอป FQDN ที่อยู่ทางเข้าส่วนตัว และเจ้าของตัวแก้ชื่อ ห้าค่านั้นอธิบายสัญญาการเข้าถึงทั้งหมด และคนถัดไปที่จะแก้ไขปัญหานี้จะถามหาค่าเหล่านั้นพอดี