การเรียก Apex ออกมาจาก Salesforce ไม่ใช่จาก VPN ของคุณ
VPN บนแล็ปท็อปให้เส้นทางแก่เบราว์เซอร์ของคุณ ไม่ใช่ให้ Apex หรือ Marketing Cloud จับคู่ผู้เรียกจริงกับเกตเวย์สาธารณะหรือการเชื่อมต่อส่วนตัวที่มีคุณสมบัติครบ
API ส่วนตัวตอบในเบราว์เซอร์ของคุณทันทีที่แล็ปท็อปเชื่อมต่อ VPN ดังนั้นการเชื่อมต่อควรจะทำงานได้ แต่กลับไม่ทำงาน เพราะโค้ดที่ทำการเรียกนั้นทำงานอยู่ที่อื่นโดยสิ้นเชิง Apex ทำงานบนเซิร์ฟเวอร์แอปพลิเคชันของ Salesforce และกิจกรรมฝั่งเซิร์ฟเวอร์ใน Marketing Cloud ทำงานในรันไทม์ของผลิตภัณฑ์นั้น ทั้งสองไม่ได้สืบทอดอุโมงค์ของแล็ปท็อปคุณ ดำเนินการเป็นขั้นตอนสั้น ๆ ดังนี้ ระบุผู้เรียก เลือกทางเข้าที่ผู้เรียกนั้นเข้าถึงได้ เชื่อมเส้นทางตั้งแต่ต้นจนจบ แล้วตรวจสอบจากรันไทม์เอง
เขียนการ์ดผู้เรียกก่อนการเปลี่ยนแปลงเครือข่ายใด ๆ
กรอกห้าช่องและปฏิเสธที่จะเดาแม้แต่ช่องเดียว ผลิตภัณฑ์ที่ใช้ดำเนินการและบริบทเป็นตัวกำหนดทุกสิ่งหลังจากนั้น จึงเริ่มจากตรงนั้นไม่ใช่จากไฟร์วอลล์ของเซิร์ฟเวอร์
| Field | What it must answer |
|---|---|
| Runtime | Which product and execution context issues the request? |
| Endpoint | Which hostname must that runtime resolve, and to what? |
| Path | Which supported public entry or private connection carries it? |
| Identity | Which credential and which operation is the API asked to authorize? |
| Failure | How do responses return, and what happens when the path is down? |
แท็บเบราว์เซอร์และการเรียก Apex เป็นไคลเอนต์สองแบบที่ต่างกัน และเบราว์เซอร์ที่ใช้งานได้พิสูจน์เพียงว่ามีเส้นทางจากโต๊ะของคุณ หากช่องรันไทม์ระบุ Apex คำถามที่เกี่ยวข้องคือ Salesforce ออกมาจากที่อยู่ใด ไม่ใช่ที่อยู่ที่แล็ปท็อปของคุณมี นั่นคือเหตุผลที่อุโมงค์ซึ่งทำให้ API โหลดในเบราว์เซอร์อาจปล่อยให้การเชื่อมต่อล้มเหลวด้วยเวลาหมดอายุเดิม การ์ดผู้เรียกมีไว้เพื่อหยุดข้อผิดพลาดนั้นก่อนที่ใครจะแก้ไขไฟร์วอลล์
เลือกทางเข้าที่ผู้เรียกใช้งานได้จริง
ทั้งสองแบบถูกต้อง และแก้ปัญหาต่างกัน แบบแรกคือทางเข้าสาธารณะโดยเจตนา เกตเวย์ API แบบ HTTPS หรือบริการเชื่อมต่อที่พิสูจน์ตัวตนผู้เรียก ใช้สิทธิ์แคบ ๆ และรักษาการเชื่อมต่อที่ป้องกันไว้กับ backend ส่วนตัว นั่นไม่เหมือนกับการเปิดเผยทุกบริการของ backend หรือส่งต่อพอร์ตบริหารไปยังอินเทอร์เน็ต
แบบที่สองคือการเชื่อมต่อส่วนตัวที่มีคุณสมบัติครบ เอกสาร Private Connect ขาออก ของ Salesforce อธิบายการกำหนดเส้นทางการเรียกที่รองรับผ่าน Outbound Network Connection ที่ผูกกับข้อมูลรับรองที่ตั้งชื่อ ตามการจัดวาง AWS PrivateLink ที่กำหนดไว้ คุณลักษณะนี้มีข้อจำกัดด้านรุ่น สัญญาอนุญาต และผลิตภัณฑ์ ดังนั้นตรวจสอบว่าองค์กรมีคุณสมบัติครบก่อนออกแบบโดยอิงคุณลักษณะนี้
ไม่มีแบบใดเป็นการติดตั้งไคลเอนต์ OpenVPN ไว้ใน Salesforce และข้อกล่าวอ้างเดิมที่ว่าทุกการเชื่อมต่อต้องเข้าถึง backend สาธารณะนั้นกว้างเกินไปในที่ที่การเชื่อมต่อส่วนตัวที่รองรับเหมาะสม เลือกแบบที่รันไทม์รองรับ แล้วทำเส้นทางไปยัง API จริงให้เสร็จ ปลายทาง AWS ไม่รู้จักทรัพยากรภายในองค์กรของคุณและไม่สืบทอดเส้นทางของแล็ปท็อปคุณ DNS การกำหนดเส้นทางของ backend นโยบายการเข้าถึง และทราฟฟิกตอบกลับทั้งหมดต้องเป็นไปตามสถาปัตยกรรมที่คุณเลือก เส้นทางส่วนตัวที่สร้างครึ่ง ๆ กลาง ๆ จะล้มเหลวในลักษณะที่ดูเหมือนปัญหาการพิสูจน์ตัวตนทุกประการ
เชื่อมเส้นทางส่วนตัวตั้งแต่ต้นจนจบ
ทำงานจาก API ออกไปข้างนอกและหยุดที่ช่องว่างแรก ยืนยันว่า backend ตอบในเครื่อง จากนั้นว่าปลายทางส่วนตัวเข้าถึงได้ และจากนั้นว่าข้อมูลรับรองที่ตั้งชื่อและการเชื่อมต่อขาออกมุ่งไปที่ปลายทางนั้น
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' http://10.40.8.20:8080/health
dig +short api.partner.example
sf apex run --file scripts/apex/callout-check.apex --target-org integrationคำสั่งแรกพิสูจน์ว่า backend สมบูรณ์จากภายในเครือข่ายส่วนตัว คำสั่งที่สองแสดงว่าชื่อแปลงเป็นอะไร และคำสั่งที่สามเรียกใช้ออกจากรันไทม์ Salesforce จริง 200 จากคำสั่งแรกและการล้มเหลวจากคำสั่งที่สามแยกช่องว่างไปที่เส้นทางหรือข้อมูลรับรอง ไม่ใช่ที่บริการ
รักษาขอบเขตของตัวตนให้แม่นยำขณะเชื่อมต่อ ข้อมูลรับรองที่ตั้งชื่อไม่สามารถซ่อมปลายทางที่เข้าถึงไม่ได้ด้วยตัวเอง เพราะข้อมูลรับรองและการเชื่อมต่อส่วนตัวเป็นการตั้งค่าที่เกี่ยวข้องกันแต่มีหน้าที่ต่างกัน รายการ IP ที่อนุญาตจำกัดการรับเข้าเครือข่ายและไม่ใช่ข้อมูลรับรอง API จึงควรรักษาการตรวจสอบ TLS ตามปกติและกระบวนการพิสูจน์ตัวตนและการหมุนเวียนของบริการเอง หากการทดสอบผ่านเฉพาะหลังจากปิดการตรวจสอบใบรับรอง แสดงว่าคุณพบปัญหาชื่อโฮสต์ไม่ใช่ปัญหาเส้นทาง และใบรับรองยังต้องตรงกัน
ตรวจสอบจากรันไทม์ แล้วบันทึกการย้อนกลับ
ยอมรับคำขอที่ได้รับอนุญาตและไม่เป็นอันตรายจากรันไทม์ของการเชื่อมต่อ ไม่ใช่จากเครื่องของคุณ บันทึกแหล่งที่มาที่สังเกตได้ของบริการที่รับ ตัวตนที่พิสูจน์แล้ว ผลลัพธ์ และคำขอหนึ่งรายการที่ถูกปฏิเสธโดยเจตนาซึ่งต้องล้มเหลว
curl -sS -o /dev/null -w '%{http_code} %{remote_ip}\n' https://api.partner.example/v1/ping
curl -sS -o /dev/null -w '%{http_code}\n' -H 'Authorization: Bearer invalid' https://api.partner.example/v1/pingรันการตรวจสอบสองอย่างเดียวกันจากเครือข่ายของ backend เอง เพื่อให้สามารถเปรียบเทียบแหล่งที่มาที่สังเกตได้กับสิ่งที่รันไทม์สร้างขึ้น 200 ตามด้วย 401 หรือ 403 คือรูปแบบที่ต้องการ สอง 200 หมายความว่าเส้นทางปฏิเสธไม่ได้ถูกบังคับใช้จริง
เขียนการย้อนกลับก่อนที่คุณจะต้องใช้ รายการที่อนุญาตรายการใด ข้อมูลรับรองที่ตั้งชื่อหรือการเชื่อมต่อขาออกใดที่คุณเปลี่ยน ใครเป็นเจ้าของ และจะคืนค่าเดิมได้อย่างไร จากนั้นปิดวงจรโดยระบุผู้เรียกบนคลาวด์และเส้นทางบริการทั้งหมดในตั๋ว เพื่อไม่ให้ใครเปิดปัญหาเดิมซ้ำในฐานะปัญหา VPN