ทำไม Apps Script จึงเข้าถึงแอปภายในของคุณผ่าน VPN ไม่ได้

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

แยกคำถามสองข้อก่อนจะเปลี่ยนอะไร: เครื่องไหนเป็นผู้ส่งคำขอ และผู้รับยอมรับข้อมูลรับรองแบบใด

คำขอไม่เคยเริ่มต้นบนแล็ปท็อปของคุณ

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

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

สิ่งที่สิ่งนี้ตัดออก

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

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

สองรูปแบบที่ทำได้จริง

รูปแบบแรกให้ API ที่ได้รับอนุมัติแก่สคริปต์ เผยแพร่บริการภายในไว้หลังเกตเวย์ที่ตรวจสอบผู้เรียก จากนั้นให้สคริปต์นำเสนอข้อมูลรับรองที่เกตเวย์ยอมรับ เช่นโทเค็นของบัญชีบริการ ใน Apps Script นั่นหมายถึงไลบรารี OAuth2 หรือ ScriptApp.getOAuthToken() พร้อมรายการอนุญาตอัตลักษณ์ผู้เรียกทางฝั่ง API แทนรายการ IP

รูปแบบที่สองกลับทิศทาง งานภายในเป็นผู้สอบถามระบบส่วนตัวและเผยแพร่ผลลัพธ์ที่ควบคุมไว้ไปยัง Sheet ออบเจกต์ Cloud Storage หรือตาราง BigQuery ที่สคริปต์อ่าน งาน Cloud Run ตัวจัดตารางเวลาในองค์กร หรือขั้นตอน ETL ที่มีอยู่แล้วล้วนเป็นงานนั้นได้ และไม่มีใครต้องยอมรับการเชื่อมต่อขาเข้า จากนั้นสเปรดชีตจะบริโภคชุดข้อมูลแทนอินเทอร์เฟซ

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

ผลลัพธ์ที่เผยแพร่ต้องมีอะไรบ้าง

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

ทิศทาง API ก็ต้องมีสัญญาเช่นกัน: เกตเวย์ยอมรับข้อมูลรับรองใด โทเค็นถือ scopes อะไร และอัตลักษณ์ผู้เรียกใดได้รับอนุญาต การตอบกลับ 200 ที่มีหน้าเข้าสู่ระบบไม่ใช่การเรียกที่สำเร็จ ดังนั้นตรวจสอบเนื้อหา ไม่ใช่แค่รหัสสถานะ

อ่านข้อผิดพลาดจากด้านที่ถูกต้อง

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

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