Apex çağrıları VPN'inizden değil, Salesforce'tan çıkar
Dizüstü VPN'i tarayıcınıza bir yol verir, Apex veya Marketing Cloud'a değil. Gerçek çağıranı genel bir ağ geçidiyle veya nitelikli bir özel bağlantıyla eşleştirin.
Dizüstü bilgisayar VPN'e katıldığı anda özel API tarayıcınızda yanıt verir, bu yüzden entegrasyonun çalışması gerekir. Çalışmıyor, çünkü çağrıyı yapan kod tamamen başka bir yerde çalışıyor. Apex, Salesforce'un uygulama sunucularında; Marketing Cloud'daki sunucu tarafı etkinlik ise o ürünün çalışma zamanında çalışır. İkisi de dizüstü bilgisayarınızın tünelini devralmaz. Bunu kısa bir yordam olarak uygulayın: çağıranı tanımlayın, o çağıranın ulaşabileceği bir giriş seçin, yolu uçtan uca bağlayın ve ardından çalışma zamanının kendisinden doğrulayın.
Herhangi bir ağ değişikliğinden önce çağıran kartını yazın
Beş alanı doldurun ve hiçbirini tahmin etmeyi reddedin. Yürütme ürünü ve bağlam sonraki her şeyi belirler, bu yüzden sunucunun güvenlik duvarından değil, oradan başlayın.
| 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? |
Bir tarayıcı sekmesi ile bir Apex çağrısı iki farklı istemcidir ve çalışan bir tarayıcı yalnızca masanızdan bir yol olduğunu kanıtlar. Çalışma zamanı alanı Apex diyorsa ilgili soru, Salesforce'un hangi adreslerden çıktığıdır; dizüstü bilgisayarınızın hangi adreslere sahip olduğu değil. Bu yüzden API'yi tarayıcıda yükleyen bir tünel, entegrasyonu öncekiyle aynı zaman aşımıyla başarısız bırakabilir. Çağıran kartı, biri güvenlik duvarını düzenlemeden önce bu hatayı durdurmak için vardır.
Çağıranın gerçekten kullanabileceği girişi seçin
İki tasarım da meşrudur ve farklı sorunları çözer. Birincisi bilinçli bir genel giriştir: çağıranı kimlik doğrulayan, dar izinler uygulayan ve özel arka uca korumalı bir bağlantı tutan bir HTTPS API ağ geçidi veya entegrasyon hizmeti. Bu, her arka uç hizmetini açığa çıkarmak veya bir yönetim bağlantı noktasını internete yönlendirmekle aynı şey değildir.
İkincisi nitelikli bir özel bağlantıdır. Salesforce'un giden Private Connect belgeleri desteklenen çağrıların adlandırılmış bir kimlik bilgisine bağlı Outbound Network Connection üzerinden, tanımlı AWS PrivateLink düzeniyle nasıl yönlendirildiğini açıklar. Özelliğin sürüm, lisans ve ürün kısıtları vardır, bu yüzden etrafında tasarım yapmadan önce kuruluşun koşulları karşıladığını doğrulayın.
Tasarımların hiçbiri Salesforce içine kurulmuş bir OpenVPN istemcisi değildir ve her entegrasyonun genel bir arka uca ulaşması gerektiği yönündeki eski iddia, desteklenen özel bağlantının uyduğu her yerde fazla geniştir. Çalışma zamanının desteklediğini seçin, sonra yolu gerçek API'ye kadar tamamlayın: bir AWS uç noktası yerel kaynağınızı bilmez ve dizüstü bilgisayarınızın rotasını devralmaz. DNS, arka uç yönlendirmesi, erişim ilkesi ve yanıt trafiği seçtiğiniz mimariyi izlemek zorundadır. Yarı inşa edilmiş özel bir yol, tam olarak kimlik doğrulama sorununa benzeyen bir şekilde başarısız olur.
Özel yolu uçtan uca bağlayın
API'den dışa doğru çalışın ve ilk boşlukta durun. Arka ucun yerel olarak yanıt verdiğini, sonra özel uç noktanın ona ulaştığını ve ardından adlandırılmış kimlik bilgisinin ve giden bağlantısının o uç noktayı hedeflediğini doğrulayın.
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İlk komut arka ucun özel ağın içinden sağlıklı olduğunu kanıtlar, ikincisi adın neye çözüldüğünü gösterir ve üçüncüsü gerçek Salesforce çalışma zamanından bir çağrı yürütür. İlkinden 200 ve üçüncüsünden başarısızlık, boşluğu hizmete değil yola veya kimlik bilgisine izole eder.
Bağlarken kimlik kapsamını kesin tutun. Adlandırılmış bir kimlik bilgisi ulaşılamayan bir uç noktayı tek başına onarmaz, çünkü kimlik bilgisi ve özel bağlantı ayrı işleri olan ilişkili ayarlardır. Bir IP izin listesi ağ kabulünü daraltır ve API kimlik bilgisi değildir, bu yüzden normal TLS doğrulamasını ve hizmetin kendi kimlik doğrulama ve döndürme sürecini koruyun. Bir test yalnızca sertifika denetimini kapattıktan sonra geçiyorsa, yol değil ana bilgisayar adı sorunu buldunuz ve sertifika yine de eşleşmelidir.
Çalışma zamanından doğrulayın, sonra geri almayı kaydedin
Kendi makinenizden değil, entegrasyonun çalışma zamanından zararsız ve izinli bir istek kabul edin. Alıcı hizmetin gözlediği kaynağı, kimliği doğrulanmış asıl kişiyi, sonucu ve mutlaka başarısız olması gereken, bilerek reddedilmiş bir isteği kaydedin.
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/pingAynı iki sondayı arka ucun kendi ağından çalıştırın, böylece gözlenen kaynak çalışma zamanının ürettiğiyle karşılaştırılabilir. 200'ü 401 veya 403'ün izlemesi istediğiniz biçimdir; iki 200, reddetme yolunun gerçekten uygulanmadığı anlamına gelir.
Geri almayı ihtiyaç duymadan önce yazın: hangi izin listesi girdisini, adlandırılmış kimlik bilgisini veya giden bağlantıyı değiştirdiniz, kim sahibi ve önceki değer nasıl geri yüklenir. Ardından bilete bulut çağıranını ve hizmetin tam yolunu yazarak döngüyü kapatın, böylece kimse aynı konuyu yeniden VPN sorunu olarak açmasın.