การเข้าถึงระยะไกลของผู้พัฒนาสู่ Google Cloud VPC: เลือกเส้นทาง

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

เขียนปลายทางและโปรโตคอลลงไป

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

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

IAP สำหรับบริการ TCP ไม่กี่รายการ

การส่งต่อ TCP ใน Identity-Aware Proxy ให้อุโมงค์ที่ผ่านการยืนยันตัวตนไปยังทรัพยากร VM ที่มีคุณสมบัติเหมาะสมโดยไม่เปิดเผยบริการสู่อินเทอร์เน็ต รูปแบบทั่วไปคือ gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a และพอร์ตเดียวสามารถส่งต่อในเครื่องได้ด้วย gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a

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

การส่งต่อ TCP ใน IAP ไม่ใช่ VPN ชั้นที่สาม มันส่ง TCP ไปยังปลายทางที่เลือก ไม่ใช่ทราฟฟิก IP ตามอำเภอใจหรือ UDP และไม่เหมาะเมื่อแอปพลิเคชันต้องการ DNS ส่วนตัวในหลายบริการ

VPN สำหรับการเข้าถึงระยะไกลเพื่อการเข้าถึงที่กว้างขึ้น

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

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

Cloud VPN เป็นเกตเวย์ของไซต์ ไม่ใช่โปรไฟล์แล็ปท็อป

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

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

ตรวจสอบและบันทึก

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

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