VPN เข้า VPC ใช้งานได้ แต่บริการที่มีการจัดการหมดเวลา
อุโมงค์สิ้นสุดที่ขอบเครือข่ายของคุณ ไม่ใช่ที่ประตูหน้าของผู้ให้บริการ จัดประเภทปลายทางว่าโฮสต์บน VM เชื่อมต่อกับ VPC หรือเป็นสาธารณะเท่านั้นก่อนเปลี่ยนเส้นทาง
การเข้าถึงฐานข้อมูลที่มีการจัดการผ่าน VPN มักล้มเหลวด้วยเหตุผลที่ไม่มีใครเขียนไว้ในคู่มือ คือ อุโมงค์สิ้นสุดที่ขอบเครือข่ายของคุณ ขณะที่บริการไม่เคยอยู่ฝั่งของคุณเลย ตารางเส้นทางดูถูกต้อง อุโมงค์รายงานว่าทำงานอยู่ แต่การเชื่อมต่อก็ยังหมดเวลา ตรวจสอบสี่ข้อด้านล่างตามลำดับและหยุดที่ข้อแรกที่เงื่อนไขผ่านไม่เป็นจริง เพราะการตรวจสอบถัดไปถือว่าข้อก่อนหน้าผ่านแล้ว
การตรวจสอบข้อหนึ่ง: ปลายทางอยู่ที่ใดจริง ๆ
เกตเวย์ VPN เชื่อมเครือข่ายสองเครือข่ายที่คุณควบคุมการกำหนดแอดเดรส บริการที่มีการจัดการทำงานอยู่หลังประตูหน้าของผู้ให้บริการเอง และประตูนั้นมีได้สามรูปแบบขึ้นกับผลิตภัณฑ์ หากคุณไม่ทราบว่ากำลังเผชิญกับรูปแบบใด การทำงานกับเส้นทางมากเท่าไรก็ไม่ช่วย เพราะความล้มเหลวอาจไม่ใช่ความล้มเหลวของเส้นทางเลย
| Shape | What it means | Pass condition |
|---|---|---|
| Software on your VM | Ordinary subnet addressing | Route and security group permit the client |
| Attached to your VPC | Private, but only inside that VPC | Endpoint associated, source allowed, route present |
| Provider-hosted, public endpoint | Optional private link, not private by default | A private endpoint exists and DNS points at it |
บ่ายที่สูญเปล่าส่วนใหญ่เกิดจากการข้ามการจัดประเภทนี้แล้วไปที่ตารางเส้นทางทันที บริการที่โฮสต์โดยผู้ให้บริการซึ่งมีปลายทางสาธารณะไม่ได้อยู่หลังอุโมงค์ของคุณไม่ว่าแผนภาพจะบอกอย่างไร และบริการที่เชื่อมต่อกับ VPC จะไม่มีวันปรากฏในคำตอบ DNS สาธารณะ
การตรวจสอบข้อสอง: บริการที่เชื่อมต่อกับ VPC เช่น ElastiCache
แคชประเภทนั้นถูกกำหนดแอดเดรสภายใน VPC ของคุณเองและไม่มีตัวรับฟังที่หันสู่อินเทอร์เน็ตเลย VPN ของไคลเอนต์ที่สิ้นสุดใน VPC เดียวกันเข้าถึงได้ แต่เฉพาะเมื่อเงื่อนไขสามข้อเกิดขึ้นพร้อมกัน ปลายทางของแคชต้องเชื่อมโยงกับซับเน็ตที่อุโมงค์ของคุณมองเห็น กลุ่มความปลอดภัยต้อง อนุญาตแอดเดรสที่ไคลเอนต์ของคุณมาจาก และฝั่งไคลเอนต์ต้องมีเส้นทางที่ครอบคลุมซับเน็ตของแคช
ข้อผิดพลาดทั่วไปคือการคิดว่าการเชื่อมต่อที่อยู่ใกล้เคียงก็นับด้วย การเชื่อม VPN กับ VPC อื่น หรือพึ่งพา peering เท่านั้น ไม่ได้ขยายกลุ่มความปลอดภัยของแคชหรือตารางเส้นทางของซับเน็ตไปถึงไคลเอนต์ของคุณ เมื่ออุโมงค์เดิมสิ้นสุดที่อื่น ทางเลือกสำรองปกติคือโฮสต์กระโดดหรือเซิร์ฟเวอร์ VPN ที่วางไว้ใน VPC นั้น ทางเลือกนั้นเป็นการอ้อมไม่ใช่การออกแบบ และควรติดป้ายในคู่มือว่าเป็นเช่นนั้น
การตรวจสอบข้อสาม: ปลายทาง PaaS ที่มีชื่อสาธารณะ
Azure Database for PostgreSQL นำเสนอชื่อเซิร์ฟเวอร์สาธารณะ ไม่ได้ให้แอดเดรสส่วนตัวที่คุณปักในไฟล์ hosts แล้วกำหนดเส้นทางผ่านเกตเวย์ได้ ปลายทางบริการของเครือข่ายเสมือนจำกัดว่าซับเน็ตใดเข้าถึงทรัพยากรได้ ไม่ได้ให้อำนาจกับไคลเอนต์ในองค์กรที่มาผ่าน VPN
การได้การเข้าถึงแบบส่วนตัวหมายถึงการนำปลายทางส่วนตัวหรือการออกแบบลิงก์ส่วนตัวมาใช้ แล้วเพิ่มโซน DNS ส่วนตัวเพื่อให้ชื่อสาธารณะตอบกลับด้วยปลายทางนั้นแทนอินเทอร์เน็ต VPN ที่รวมกับกฎปลายทางบริการเป็นสถาปัตยกรรมอีกแบบที่ดูคล้ายกันเฉพาะในแผนภาพ App Service ใช้ตรรกะเดียวกันจากทิศทางตรงข้าม คือ การรวม VNet ทำให้แอปเรียกออกไปใน VNet ได้ และไม่ได้สร้างเส้นทางส่วนตัวขาเข้าจากอุโมงค์ของคุณ ดังนั้นการเข้าถึงแบบส่วนตัวขาเข้าจึงต้องมีปลายทางส่วนตัว สภาพแวดล้อม App Service หรือเกตเวย์หน้าแอป และจะใช้สิ่งใดได้ขึ้นกับแพ็กเกจ
การตรวจสอบข้อสี่: ผลิตภัณฑ์ที่มีประตูหน้าของตนเอง
Firebase Hosting เชื่อมต่อกับ Cloud VPN ไม่ได้ เพราะชั้นโฮสติ้งเป็นส่วนหน้าแบบทั่วโลก ไม่ใช่สิ่งที่อยู่ภายใน VPC ของโปรเจกต์ ทางเลือกที่บันทึกไว้คือสร้างจุดเข้าที่ควบคุมได้ด้วยตนเอง ด้วยอินสแตนซ์พร็อกซีหรือโหลดบาลานเซอร์ที่หนุนด้วยบัคเก็ต ไม่ว่าจะทางใด เว็บไซต์ก็เลิกเป็นผลิตภัณฑ์โฮสติ้งล้วนและกลายเป็นโครงสร้างพื้นฐานที่คุณดำเนินการเองในตอนนี้ การแลกเปลี่ยนนั้นควรถูกเอ่ยถึงก่อนที่ใครจะสัญญาว่าอุโมงค์จะครอบคลุมมัน
Private API Gateway อยู่ใกล้ฝั่งบริการของ VPC มากกว่า ปลายทาง VPC ชนิด interface เผยแพร่ชื่อโฮสต์ที่คำตอบเป็นแอดเดรสส่วนตัว และทราฟฟิกจากสถานที่ของคุณมาทางอุโมงค์หรือการเชื่อมต่อเฉพาะ ปลายทางต้องเชื่อมโยงกับ API และใบรับรองพร้อมชื่อโฮสต์ต้องตรงกับโดเมนที่ผู้เรียกใช้กำหนดเอง
อุโมงค์ของ Google Cloud VPN ผูกกับแอดเดรส IP ของคู่สัญญา ไม่ใช่ชื่อ การส่งต่อ DNS กำหนดค่าแยกกัน จึงเป็นเหตุให้อุโมงค์สมบูรณ์ดีแต่การค้นหาในโซนส่วนตัวระยะไกลยังล้มเหลว
จากนั้นระบุขอบเขต
เรียกใช้การเชื่อมต่อเดียวกันจาก VM ภายใน VPC เมื่อสำเร็จที่นั่นแต่ล้มเหลวจากไคลเอนต์ VPN ช่องว่างอยู่ระหว่างเส้นทางของไคลเอนต์กับปลายทางของบริการ คือ เส้นทาง กลุ่มความปลอดภัย นโยบายปลายทาง หรือชื่อ เมื่อทั้งสองความพยายามล้มเหลว ไม่มีสิ่งใดในเครือข่ายนั้นเข้าถึงบริการได้ และ VPN ไม่เคยเป็นอุปสรรค
getent hosts db.internal.example
nc -vz db.internal.example 5432ทำการค้นหาชื่อและการตรวจสอบพอร์ตแยกกัน เพราะมันล้มเหลวด้วยเหตุผลต่างกัน และคู่นั้นบอกคุณว่าครึ่งใดของเส้นทางเสียหาย ชื่อที่แปลงเป็นแอดเดรสสาธารณะกำลังบอกคุณว่า โซน DNS ส่วนตัวไม่ได้ผล