Azure P2S VPN ไม่สามารถแปลงชื่อปลายทางส่วนตัวได้

คุณเชื่อมต่ออุโมงค์ point-to-site, ping ที่อยู่ส่วนตัว, เปิดแอป แล้วได้ 403 หรือข้อผิดพลาดใบรับรองแทน อาการทั้งสองชี้ไปที่ DNS แต่เป็นความผิดพลาดที่ต่างกัน: อย่างหนึ่งหมายถึงไคลเอนต์แปลงที่อยู่สาธารณะ อีกอย่างหมายถึงแปลงที่อยู่ส่วนตัวแล้วเสนอชื่อที่ใบรับรองไม่ครอบคลุม ทำตามการตรวจด้านล่างตามลำดับและหยุดที่ความล้มเหลวแรก เพราะรายการ hosts หรือคำตอบที่แคชไว้ทำให้การตรวจครั้งต่อไปผ่านด้วยเหตุผลผิดได้ ฉันเก็บลำดับนี้ไว้ในไฟล์ข้อความข้างโปรไฟล์ VPN เพราะการแก้ไขไม่เปลี่ยนอะไรในอุโมงค์และเปลี่ยนทุกอย่างในสิ่งที่ไคลเอนต์รู้

เริ่มจากที่อยู่ที่ไคลเอนต์ได้รับจริง

ถามตัวแปลงชื่อโดยตรงแทนที่จะเชื่อแอปพลิเคชัน บน Windows nslookup adminuidev-fedqcubyd9bfb2bq.canadacentral-01.azurewebsites.net แสดงว่าไคลเอนต์ได้รับมุมมองใด คำตอบสาธารณะหมายความว่าไม่มีอะไรต่อไปจะไปถึงปลายทาง ที่อยู่ส่วนตัวของปลายทางหมายความว่า DNS เสร็จแล้วและการตรวจครั้งต่อไปคือการเชื่อมต่อเอง

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

ตรวจโซน ลิงก์ของโซน และระเบียนก่อนอุโมงค์

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

ชื่อโซนเป็นของบริการ ไม่ใช่ของลิงก์ส่วนตัวโดยทั่วไป App Service มักใช้ privatelink.azurewebsites.net ที่เก็บข้อมูลและ SQL มีเนมสเปซของตัวเอง และการยืมโซนของบริการอื่นทำให้ได้โซนที่มีอยู่แต่ไม่ตอบอะไรที่เป็นประโยชน์

ให้ตัวแปลงชื่อที่ไคลเอนต์เข้าถึงได้จริง

168.63.129.16 ตอบจากเครื่องเสมือนของ Azure และไม่ใช่เซิร์ฟเวอร์ DNS สำหรับแล็ปท็อปอีกด้านของอุโมงค์ point-to-site ไคลเอนต์ต้องการตัวแปลงชื่อที่เข้าถึงได้ผ่านอุโมงค์: ปลายทางขาเข้าของ Azure DNS Private Resolver ตัวส่งต่อภายในเครือข่ายเสมือน หรือรายการเซิร์ฟเวอร์ DNS ที่บรรจุในโปรไฟล์ไคลเอนต์ VPN เพื่อให้ไคลเอนต์ถามเครือข่ายเสมือนโดยตรง

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

หากส่งต่อแทนการดันการตั้งค่า ให้ส่งต่อเนมสเปซที่โซนส่วนตัวเป็นเจ้าของ คือ privatelink.azurewebsites.net ไม่ใช่ azurewebsites.net ทั้งหมด ตัวส่งต่อแบบมีเงื่อนไขที่กลืนซัฟฟิกซ์แม่ทั้งหมดจะส่งทุกการค้นหาของบริการไปยัง Azure รวมถึงรายการที่ควรอยู่ภายใน

ใช้ชื่อที่ใบรับรองออกให้

เมื่อที่อยู่ถูกต้อง ความผิดพลาดที่สองก็ปรากฏขึ้น ที่เก็บข้อมูลและ App Service เผยแพร่ alias privatelink และ alias นั้นไม่จำเป็นต้องเป็นชื่อในใบรับรอง การอัปโหลด AzCopy ที่ส่งไปยัง privatelink.blob.core.windows.net ไม่ผ่านการตรวจสอบ การอัปโหลดเดียวกันไปยัง <account>.blob.core.windows.net/<container> แปลงเป็นที่อยู่ส่วนตัวและผ่านไปได้ จึงยังอยู่ในเส้นทางส่วนตัวโดยไม่มีการข้ามใด ๆ

กฎนี้ใช้ในเบราว์เซอร์และกับ App Service ด้วย: เชื่อมต่อด้วยชื่อโฮสต์ที่ใบรับรองครอบคลุมและให้ DNS จัดหาที่อยู่ส่วนตัว อย่าเอื้อมไปหาการข้ามการตรวจสอบ เพราะมันเปลี่ยนข้อผิดพลาดในการตั้งชื่อให้เป็นการถอยหลังด้านความปลอดภัย ping ที่สำเร็จพิสูจน์เส้นทางและไม่บอกอะไรเกี่ยวกับชื่อภายในแฮนด์เชก นั่นคือเหตุผลที่ยังเป็นการตรวจแยกกัน

ลำดับสี่ขั้นที่แยกแต่ละชั้น

1. ยืนยันว่าไคลเอนต์ VPN มีที่อยู่จากพูล point-to-site และมีเส้นทางไปยังที่อยู่ส่วนตัวของปลายทาง
2. แปลงชื่อที่แน่นอนที่แอปใช้และเปรียบเทียบคำตอบกับที่อยู่ของปลายทาง
3. เปิดการเชื่อมต่อ TCP ไปยังปลายทางที่พอร์ตของบริการ แล้วอ่านชื่อใบรับรองที่นำเสนอในการเชื่อมต่อนั้น
4. เพิ่งทดสอบการอนุญาตตอนนี้ เพราะเส้นทางที่ใช้งานได้และใบรับรองที่ถูกต้องยังไม่ให้สิทธิ์เข้าถึงทรัพยากร

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

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

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

รายการ hosts ควรอยู่ที่ไหน

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

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

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