Google API ผ่าน VPN: เส้นทางต้องไปที่ VIP ไม่ใช่แค่ซับเน็ต

เข้าเซิร์ฟเวอร์ภายในผ่าน SSH ยกทันเนลขึ้น แล้ว VM ส่วนตัวตอบกลับ จากนั้นการเรียก Google API ครั้งแรกก็ล้มเหลวเพราะไม่มีเส้นทาง ซับเน็ตของ VM กับที่อยู่ VIP ของ API เป็นปลายทางคนละแบบ ดังนั้นเส้นทางของอย่างหนึ่งจึงไม่เลือกอีกอย่าง ต้องเป็นจริงสามข้อก่อนที่การเรียก API แบบส่วนตัวจะทำงานได้ ชื่อ API ต้องแก้เป็น VIP คำนำหน้า VIP ต้องถูกประกาศผ่านทันเนล และ VPC ต้องรู้ว่าจะส่งคำตอบกลับอย่างไร ping ไม่บอกอะไรเลยในเรื่องนี้ และเซสชัน SSH ที่ใช้งานได้ไปยังเครื่องในซับเน็ตก็ไม่บอกเช่นกัน

ที่อยู่ VIP ของ API เป็นปลายทางแยกกัน

Google เผยแพร่ VIP เฉพาะสำหรับการเข้าถึง API จากเครือข่ายภายใน และที่อยู่เหล่านั้นคือสิ่งที่ DNS ของคุณต้องตอบกลับสำหรับชื่อ API ทั้งคู่เป็นคำนำหน้าเล็ก ๆ และไม่มีอันใดเป็นพื้นที่ RFC 1918:

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

DNS ตัดสินว่าคุณไปถึงปลายทางใด

ชี้ตัวแก้ชื่อภายในไปที่ระเบียนที่ Google เอกสารไว้สำหรับปลายทางที่เลือก เพื่อให้ชื่อที่แอปพลิเคชันต้องการตอบด้วย VIP นั้น การแมปเพียง googleapis.com ไม่ใช่บัญชีรายการ ทะเบียนแพ็กเกจ ทะเบียนคอนเทนเนอร์ และตัวเชื่อมการย้ายข้อมูลมีชื่อที่เอกสารไว้เป็นของตัวเอง VIP แบบจำกัดก็ไม่ได้รองรับทุกบริการ ชื่อที่แก้ได้จึงอาจยังไม่ได้รับการรองรับ จดโดเมนที่แอปพลิเคชันติดต่อจริงก่อนจะแตะตัวแก้ชื่อ

การเดาที่อยู่ VM ใน VPC แทนชื่อบริการไม่ใช่การแก้ไข และมักซ่อนช่องว่างของ DNS ไว้จนกว่าไคลเอนต์อื่นจะล้มเหลว

ประกาศคำนำหน้า VIP และเก็บส่วนที่เหลือไว้

ในการเชื่อมต่อที่ใช้ BGP Cloud Router ต้องประกาศคำนำหน้า VIP ที่เลือก เพื่อให้เราเตอร์ภายในเรียนรู้ช่วงนั้นผ่านเซสชันที่ตั้งใจ การประกาศเฉพาะซับเน็ตของ VPC ไม่ได้เพิ่มช่วงนั้น และเราเตอร์ภายในยังใช้เส้นทางเริ่มต้นของตนสำหรับที่อยู่เหล่านั้น คำนำหน้าในตารางเส้นทางเป็นหลักฐานเดียวว่าการประกาศข้ามเซสชันไปแล้ว

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

ฝั่ง VPC ต้องมีเส้นทางและเส้นทางกลับของตัวเอง

ภายใน VPC เส้นทางไปยัง VIP ต้องใช้เกตเวย์อินเทอร์เน็ตเริ่มต้นเป็นฮอปถัดไป และแม้ชื่อจะเป็นเช่นนั้น ทราฟฟิกนั้นก็ยังอยู่ในเครือข่ายของ Google VPC ยังต้องมีเส้นทางกลับไปยังต้นทางภายในผ่าน VPN ซึ่งเป็นออบเจกต์แยกจากคำนำหน้าที่ประกาศไว้ ต้องคำนึงถึงข้อกำหนดการกำหนดเส้นทางระดับภูมิภาคที่เอกสารไว้ เมื่อทันเนลกับไคลเอนต์ไม่ได้อยู่ในภูมิภาคเดียวกัน

ตรวจสอบเส้นทางกลับแยกต่างหาก เพราะทิศทางของคำขอที่ทำงานได้อาจซ่อนทิศทางของคำตอบที่เสียไว้ สองทิศทาง สองเส้นทาง และแต่ละอย่างล้มเหลวด้วยอาการของตัวเอง

ทดสอบคำขอ แล้วอ่านการปฏิเสธ

ICMP echo ไม่ได้รับคำตอบจาก VIP เหล่านี้ ping ที่ล้มเหลวจึงไม่พิสูจน์อะไร และ ping ที่สำเร็จพิสูจน์ได้น้อยมาก จากไคลเอนต์จริง ให้ตรวจคำตอบของชื่อและเส้นทางที่เลือก แล้วส่งคำขอ HTTPS ที่ได้รับอนุญาตไปยังบริการที่คุณสนใจ หากคำขอไปถึงบริการและถูกปฏิเสธ ให้ดูข้อมูลรับรอง IAM และนโยบายขอบเขตบริการใด ๆ ที่ใช้บังคับ

การกำหนดเส้นทางแบบส่วนตัวไม่ได้ให้สิทธิ์ API และไม่ได้เปลี่ยนสิ่งที่ตัวตนได้รับอนุญาตให้ทำ ความสำเร็จในการรับส่งกับคำตอบที่ได้รับอนุญาตเป็นผลลัพธ์คนละอย่าง และคุณต้องมีทั้งสอง รักษาเส้นทาง IPv6 ให้ชัดเจนด้วย เพราะการกำหนดคำนำหน้า IPv4 ไม่ได้บอกอะไรเกี่ยวกับไคลเอนต์ที่ชอบ IPv6

คู่มือของ Google เกี่ยวกับ Private Google Access จากเครือข่ายภายใน ครอบคลุมระเบียน DNS และข้อกำหนดการกำหนดเส้นทางไว้ด้วยกัน ดังนั้นเปรียบเทียบการตั้งค่าตัวแก้ชื่อและการประกาศของคุณกับคู่มือนี้ ไม่ใช่กับโพสต์ในฟอรัม จากนั้นรันคำขอเดิมอีกครั้งและบันทึกคำตอบกับเส้นทางไว้ในตั๋วเดียวกัน