Sağlayıcı ve dış erişim sorunları
Kaydedilemeyen kimlik bilgileri, modele ulaşmadan başarısız olan sohbet istekleri, hız sınırları ve sağlayıcıya hiç erişemeyen bir cihaz.
- Sürüm: 0.4
- Rol: admin_user
- Tür: sorun giderme
"Anahtar doğru" ile yanıtın akmaya başlaması arasındaki her şey. Belirtiyi tablodan bulun, sonra altındaki çalışma kitabını izleyin.
Sohbet penceresinden bakıldığında birbirinin aynısı görünen dört ayrı arıza vardır: katalogda model yoktur, hiçbir kimlik bilgisi çözümlenmez, kimlik bilgisi sağlayıcı tarafından reddedilir ve sağlayıcıya hiç ulaşılamaz. Aşağıdaki çalışma kitapları bunları bu sırayla ayırır, çünkü her biri bir sonrakinden daha ucuza denetlenir.
Belirtinizi bulun
| Gördüğünüz | Çalışma kitabı |
|---|---|
| Sağlayıcı ya da model listesi boş | Katalogda hiç sağlayıcı yok |
| Bir kimlik bilgisi kaydedilmiyor ya da testi başarısız oluyor | Kimlik bilgisi reddediliyor |
| Sohbet, bir sağlayıcı, model ya da kimlik bilgisi adı vererek anında başarısız oluyor | Sohbet isteği modele ulaşmadan başarısız oluyor |
| Her şey zaman aşımına uğruyor ama ağ ekibi ağın açık olduğunu söylüyor | Cihaz dışarı çıkamıyor |
| İstekler çok sık diye reddediliyor ya da kota tükeniyor | Hız sınırları ve kotalar |
Bir API istemcisi cid_key_ belirteciyle 401 alıyor | Ağ geçidi API anahtarı reddediliyor |
Katalog
Katalogda hiç sağlayıcı yok
Sağlayıcılar ve modeller koda değil, tohum verisine dayanır. Satır yoksa hiçbir model kimliği çözümlenmez ve her tamamlama ilk aramada başarısız olur — daha hiçbir kimlik bilgisi ya da ağ yolu devreye girmeden.
Katalogda hiç LLM sağlayıcısı yok, bu yüzden her tamamlama başarısız oluyor
Şunları görebilirsiniz: No LLM providers are in the catalogue (katalogda hiç LLM sağlayıcısı yok) · sohbet bir modeli çözümleyemiyor · model açılır listesi boş · her tamamlama bir model hatasıyla başarısız oluyor
Başlamadan önce
Denetimler
- 1
Katalog koda gömülü değil veritabanından okunduğu için, ağ geçidinin veritabanına erişebildiğini doğrulayın
tanılama · datastores.postgres.reachable = true
- 2
Sağlayıcı ve model tablolarının güncel biçiminde olması için bekleyen geçiş bulunmadığını doğrulayın
tanılama · datastores.postgres.migrationsPending
- 3
Ağ geçidinden model kataloğunu isteyin
GET /models
Nedenler ve düzeltmeler
| Ne zaman ulaşılır | Neden | Açıklama, düzeltme ve doğrulama |
|---|---|---|
| denetim 3 başarısız olduğunda | catalogue-never-seeded (kritik) | Sağlayıcı ve model satırları koddan değil veritabanı tohumlayıcısından gelir. Tohumlama tümüyle kapalıyken hazırlanmış bir kutunun kataloğu boştur ve sohbet hiçbir istek için model çözümleyemez. Bozuk bir şey yoktur: satırlar hiç eklenmemiştir. Düzeltme: Örnek hesaplar kapalı durumdayken tohumlayıcıyı bu veritabanına karşı bir kez çalıştırın; böylece katalog, gösterim kullanıcıları oluşturulmadan yerine oturur. Ardından sayfayı yeniden yükleyin. Tohum yalnızca sağlayıcıları ve modelleri ekler; kimlik bilgilerini eklemek size kalır. Doğrulama: GET /models |
| denetim 1 başarısız olduğunda | database-unreachable (kritik) | Ağ geçidi veritabanına erişemiyor; dolayısıyla her liste görünür bir hata vermek yerine boş döner. Model kataloğu, boşluğu ürünü çalışmaz kılan liste olmasıyla ayrılır. Düzeltme: Ağ geçidinden PostgreSQL ya da Redis'e erişilemiyor yolunu izleyin, ardından kataloğu yeniden denetleyin. Doğrulama: tanılama · datastores.postgres.reachable = true |
| denetim 2 başarısız olduğunda | schema-behind (kritik) | Bekleyen geçişler, sağlayıcı ya da model tablolarında geçerli kodun seçtiği sütunların bulunmadığı anlamına gelir; sorgu bu yüzden başarısız olur ya da hiçbir şey döndürür ve katalog boş okunur. Düzeltme: Bekleyen geçişleri uygulayın ve ağ geçidini yeniden başlatın. Bkz. Bekleyen geçişler var. Doğrulama: tanılama · datastores.postgres.migrationsPending |
Kimlik bilgileri
Kimlik bilgisi reddediliyor
Bu ekranda birbiriyle ilgisiz üç ret bir araya gelir: uç nokta doğrulayıcısı saklamayacağı bir URL'yi reddeder, atama kuralı hem bir kiracıya hem bir gruba bağlanmış kimlik bilgisini reddeder ve sağlayıcı anahtarın kendisini reddeder. Yalnızca üçüncüsü anahtarla ilgilidir.
Note
Sağlayıcı anahtarları v1: önekli AES-256-GCM şifreli metin olarak saklanır ve pano üzerinden
asla geri okunamaz. Saklananı doğrulamanın tek yolu anahtarı yeniden yazmaktır. Dönüştürücü
eklenmeden önce yazılmış değerler olduğu gibi geçer; bu yüzden eski bir kurulumdaki geçmişten
kalma bir satır hâlâ düz metin olabilir.
Sağlayıcı kimlik bilgisi kaydedilmiyor ya da testi başarısız oluyor
Şunları görebilirsiniz: Invalid Anthropic API key (geçersiz Anthropic API anahtarı) · Test failed to run (test çalıştırılamadı) · Failed to create credential (kimlik bilgisi oluşturulamadı) · Failed to update credential (kimlik bilgisi güncellenemedi)
Başlamadan önce
Denetimler
- 1
Uç nokta taşıyan bir kimlik bilgisinde (Azure OpenAI ya da kendi barındırdığınız herhangi bir uç nokta) ret iletisinin tam metnini okuyun
beklenen · Uç nokta, bağlantı yerel alana çözümlenmeyen mutlak bir http(s) adresi.
- 2
Kimlik bilgisinin neye atandığını denetleyin
beklenen · İkisinden tam olarak biri dolu.
- 3
Anahtarı suçlamadan önce cihazın sağlayıcıya hiç ulaşıp ulaşamadığını denetleyin
tanılama · appliance.egress
- 4
Kimlik bilgisi testinin gerçekte ne bildirdiğini okuyun
beklenen · Test başarılı oluyor.
Nedenler ve düzeltmeler
| Ne zaman ulaşılır | Neden | Açıklama, düzeltme ve doğrulama |
|---|---|---|
| denetim 1 başarısız olduğunda | endpoint-refused-by-validator (uyarı) | Ağ geçidi, saklamadan önce her giden uç noktayı doğrular (config/outbound-url.ts): bir URL olarak çözümlenmeli, http ya da https olmalı ve bağlantı yerel ya da bulut örnek üstverisi alanına çözümlenmemelidir. Sonuncusu bir SSRF korumasıdır ve CID'yi aynı ana makinedeki bir model sunucusuna yönlendirenleri şaşırtan kuraldır.Düzeltme: Uç noktayı, yönlendirilebilir bir adrese çözümlenen mutlak bir https://host[:port]/path adresi olarak verin. Cihazın yanındaki bir model sunucusu için bağlantı yerel bir adres yerine kapsayıcı adını ya da yerel ağ adını kullanın.Doğrulama: beklenen · Form kabul ediyor. |
| denetim 2 başarısız olduğunda | assignment-not-exclusive (bilgi) | Bir kimlik bilgisi tek bir kiracıya ya da tek bir kiracı grubuna aittir, asla ikisine birden — veritabanının ai_credentials üzerinde zorunlu kıldığı XOR kısıtının aynısı. Her iki değeri de taşıyan bir form, hiçbir şey yazılmadan reddedilir.Düzeltme: İkisinden kastetmediğiniz atamayı temizleyin, sonra kaydedin. Doğrulama: beklenen · Form kabul ediyor. |
| denetim 3 başarısız olduğunda | cannot-reach-provider (kritik) | Sağlayıcı çağrısı, başka her giden istek gibi cihazdan çıkar. Dışarı çıkış engellenmişse ya da yapılandırılmamış bir vekil sunucudan geçmesi gerekiyorsa sağlayıcı hiç yanıt vermez ve arıza bir kimlik bilgisi sorunu olarak bildirilir. Düzeltme: Cihaz dışarı çıkamıyor yolunu izleyin. Doğrulama: tanılama · appliance.update.channelReachable = true |
| denetim 4 başarısız olduğunda | key-rejected-upstream (kritik) | Anahtarı sağlayıcının kendisi reddetmiştir. Olağan nedenler şunlardır: başka bir kuruluşa ya da projeye ait bir anahtar, sağlayıcıda döndürülmüş bir anahtar ya da uç noktası ile anahtarı farklı kaynaklara ait bir Azure dağıtımı. Düzeltme: Anahtarı sağlayıcıda yeniden üretip yeniden yapıştırın. Anahtarlar AES-256-GCM şifreli metin olarak saklanır ve pano üzerinden asla geri okunamaz; bu yüzden saklananı doğrulamanın tek yolu anahtarı yeniden yazmaktır. Azure OpenAI için uç nokta adresini aynı kimlik bilgisine girin — sağlayıcı bu olmadan çağrılamaz. Doğrulama: beklenen · Test başarılı oluyor. Bu geçerli değilse: Destek paketini ve testin tam iletisini ekleyin; anahtarı eklemeyin. |
Sohbet isteği modele ulaşmadan başarısız oluyor
Ağ geçidi önce model satırını, sonra bir kimlik bilgisini çözümler, ardından sağlayıcıyı çağırır. Her adımdaki arıza kullanıcıya aynı görünür ama farklı bir düzeltme gerektirir — ve pasif bir model, o modeli adıyla çağıran her istemciyi bozar; dün çalışan istemciler dahil.
Sohbet isteği modele ulaşmadan başarısız oluyor
Şunları görebilirsiniz: Provider 'openai' not found (sağlayıcı bulunamadı) · Model 'gpt-4o' not found (model bulunamadı) · Model 'gpt-4o' is not active (model etkin değil) · Model not found for provider (sağlayıcı için model bulunamadı)
Başlamadan önce
Denetimler
- 1
Sağlayıcı ve model katalogunun hiç dolu olup olmadığını denetleyin
beklenen · Sağlayıcılar ve modeller listeleniyor.
- 2
Çağıranın adını verdiği modelin var olup olmadığını ve etkin olup olmadığını okuyun
beklenen · Model listede ve etkin.
- 3
Bu çağıran ve bu sağlayıcı için bir kimlik bilgisinin çözümlendiğini denetleyin
beklenen · Etkin bir kimlik bilgisi çözümleniyor.
- 4
Çözümlenen kimlik bilgisini test edin
beklenen · Test başarılı oluyor.
Nedenler ve düzeltmeler
| Ne zaman ulaşılır | Neden | Açıklama, düzeltme ve doğrulama |
|---|---|---|
| denetim 1 başarısız olduğunda | catalogue-empty (kritik) | Sağlayıcılar ve modeller koda değil, tohum verisine dayanır. Satır yoksa hiçbir model kimliği çözümlenmez ve her tamamlama ilk aramada başarısız olur. Düzeltme: Katalogda hiç LLM sağlayıcısı yok yolunu izleyin. Doğrulama: beklenen · Sağlayıcılar ve modeller listeleniyor. |
| denetim 2 başarısız olduğunda | model-inactive-or-absent (uyarı) | Ağ geçidi, kimlik bilgisini çözümlemeden önce model satırını çözümler ve pasif bir modeli sessizce başkasıyla değiştirmek yerine reddeder. Bu nedenle katalogda pasifleştirilen bir model, o modeli adıyla çağıran her istemciyi bozar; dün çalışan istemciler dahil. Düzeltme: Modeli Modeller altında yeniden etkinleştirin ya da istemciyi etkin bir modele yöneltin. Model kimliğini sabit yazan bir istemci, o kimliğin etkin kalmasına ihtiyaç duyar. Doğrulama: beklenen · Tamamlama akmaya başlıyor. |
| denetim 3 başarısız olduğunda | no-credential-resolves (kritik) | Kimlik bilgileri önce kiracıda aranır, sonra kiracının grubuna düşülür. Hiçbir gruba üye olmayan bir kiracı ya da kimlik bilgisi pasifleştirilmiş bir grup hiçbir şeye çözümlenmez; dolayısıyla istek, sağlayıcıya hiç çağrı yapılmadan başarısız olur. Düzeltme: O sağlayıcı için kiracıya etkin bir kimlik bilgisi ekleyin ya da kiracıyı hâlihazırda böyle bir kimlik bilgisi taşıyan bir gruba ekleyin. Bkz. Kimlik Bilgileri. Doğrulama: beklenen · Tamamlama akmaya başlıyor. |
| denetim 4 başarısız olduğunda | credential-rejected (kritik) | Bir kimlik bilgisi çözümlenir ve sağlayıcı onu reddeder; dolayısıyla arıza, kimlik bilgisinin yapılandırıldığı sayfada değil sohbet yolunda ortaya çıkar. Düzeltme: Sağlayıcı kimlik bilgisi kaydedilmiyor ya da testi başarısız oluyor yolunu izleyin. Doğrulama: beklenen · İkisi de başarılı oluyor. Bu geçerli değilse: Destek paketini ve isteğin model kimliğini, kiracısını ve zaman damgasını ekleyin. |
Dış erişim
Cihaz dışarı çıkamıyor
Ad çözümlemesi, 443 üzerinde bir TCP bağlantısı ve site vekil sunucusu üzerinden kimlik doğrulamalı bir istek birbirinden bağımsız olarak başarısız olur. Hiç iletilmeyen bir anahtar, tam olarak yanlış bir anahtar gibi başarısız olur; hiçbir şey çalışmıyorsa dış erişim denetimi bu yüzden kimlik bilgisi denetiminden önce gelir.
Cihaz dışarı çıkamıyor — bir ya da daha fazla çıkış testi başarısız
Şunları görebilirsiniz: egress tests failed (dışarı çıkış denemeleri başarısız oldu) · cihaz imaj kayıt defterine erişemiyor · ETIMEDOUT after 5000ms (5000 ms sonra zaman aşımı) · proxy returned 407 Proxy Authentication Required (vekil sunucu 407 döndürdü — vekil kimlik doğrulaması gerekli)
Başlamadan önce
Denetimler
- 1
Cihazın giden denemelerini gerçekten çalıştırdığını doğrulayın
tanılama · appliance.egress
- 2
Cihazın erişmesi gereken ana bilgisayarlar için ad çözümleme sonuçlarını okuyun
tanılama · appliance.dns
- 3
Cihazda giden bir vekil sunucunun yapılandırılmış olup olmadığını okuyun
tanılama · appliance.proxy.configured = true
- 4
Son denemede sürüm kanalının yanıt verip vermediğini okuyun
tanılama · appliance.update.channelReachable = true
- 5
TLS denetleyen bir aygıtın cihaza kendi sertifikasını sunup sunmadığını denetleyin
beklenen · Düzenleyen, kuruluşunuzun denetim CA'sı değil genel bir sertifika otoritesi.
Nedenler ve düzeltmeler
| Ne zaman ulaşılır | Neden | Açıklama, düzeltme ve doğrulama |
|---|---|---|
| denetim 1 başarısız olduğunda | probes-disabled (bilgi) | Bu dağıtımda giden denemeler kapatılmıştır; dolayısıyla anlık görüntü hiçbir yönde kanıt taşımaz ve hiçbir dışarı çıkış bulgusu tetiklenemez. Bu, dışarıya hiç istek yapmaması gereken bir kutu için bilinçli bir ayardır. Düzeltme: Ağ geçidi kapsayıcısındaki tanılama dışarı çıkış denemelerini yeniden etkinleştirip anlık görüntüyü yeniden toplayın ya da üç testi cihazın ana makinesinde elle çalıştırın. Cihazın kendiliğinden yaptığı tek giden istek bu denemelerdir. Doğrulama: tanılama · appliance.egress |
| denetim 2 başarısız olduğunda | dns-broken (kritik) | Cihaz, bu ağın çözümleyicisiyle ad çözer. Sağlayıcı ya da kanal ana bilgisayarları için yanıt veremeyen bir çözümleyici her giden çağrıyı aynı biçimde başarısız kılar; bir dizüstündeki tarayıcı ise DNS-over-HTTPS üzerinden çözümlediği için çalışmayı sürdürür. Bu düzelene kadar çözümlemenin aşağısındaki hiçbir şey tanılanamaz. Düzeltme: Anlık görüntünün DNS bölümündeki ana bilgisayarlar için yanıt veren bir çözümleyici ayarlayın, ardından anlık görüntüyü yeniden toplayın. Bkz. Ağ ön koşulları. Doğrulama: tanılama · appliance.dns |
| denetim 3 başarısız olduğunda | proxy-not-configured (kritik) | Bu saha giden bir vekil sunucu zorunlu kılıyor ve cihazda hiç yok; dolayısıyla her giden bağlantı doğrudan denenir ve zaman aşımına uğrar. Bir zaman aşımı, eksik bir ayar gibi değil ölü bir ağ gibi okunur; ağın açık bildirilmesinin nedeni budur. Düzeltme: Giden vekil sunucuyu cihazda yapılandırın ve ayarı yeniden okuması için ağ geçidi kapsayıcısını yeniden başlatın. Docker'ın kendisi ne kabuk ortamını ne de apt'ın yapılandırmasını okur; dolayısıyla yalnızca kabuk için ayarlanmış bir vekil imaj çekmelerine ulaşmaz. Doğrulama: tanılama · appliance.proxy.configured = true |
| denetim 4 başarısız olduğunda | https-path-blocked (kritik) | Adlar çözümleniyor ama HTTPS yolu tamamlanmıyor. Ad çözümleme, 443 üzerinde bir TCP bağlantısı ve kimlik doğrulamalı bir HTTPS isteği birbirinden bağımsız olarak başarısız olur: ICMP'ye izin verip 443'ü engelleyen bir güvenlik duvarı olağandır ve Ubuntu'nun yansıları 80 portundan sunulur, dolayısıyla bu başarısız olurken ping de apt de başarılı olur. Üç test birbirinin yerine geçmez. Düzeltme: Cihazdan, anlık görüntünün başarısız olarak adını verdiği ana bilgisayarlara doğrudan giden HTTPS'e izin verin ya da bunları saha vekil sunucusuna yönlendirip vekili cihazda yapılandırın. Bir kuralı değiştirmeden önce anlık görüntüde başarısız olan her hedefin ayrıntı satırını okuyun — 407 bir vekil kimlik bilgisi sorunudur, zaman aşımı engellenmiş bir yoldur, TLS hatası ise denetimdir. Doğrulama: tanılama · appliance.update.channelReachable = true |
| denetim 5 başarısız olduğunda | tls-inspection-untrusted (kritik) | Bir ara aygıt TLS'i sonlandırıp cihazın güvenmediği bir sertifika sunar; bağlantı bu yüzden el sıkışmada başarısız olur. Ayrıntı satırı zaman aşımı değil bir TLS hatası bildirir; bunu engellenmiş bir porttan ayırmanın tek yolu da budur. Düzeltme: Denetim aygıtına güvenmesi için sahanızın CA sertifikasını cihaza kurun ya da cihazın giden hedeflerini denetimden muaf tutun. İkisi de meşrudur; güvenlik ekibinizin zaten işlettiğini seçin. Doğrulama: beklenen · Başarısız olan dışarı çıkış hedefleri ok bildiriyor ya da düzenleyene artık cihaz tarafından güveniliyor. |
Note
TLS denetleyen bir ara aygıt zaman aşımı değil, bir TLS error (TLS hatası) üretir. Bir güvenlik duvarı kuralını değiştirmeden önce tanılama anlık görüntüsünde başarısız olan her hedefin ayrıntı satırını okuyun: 407 vekil sunucu kimlik bilgisi sorunudur, zaman aşımı engellenmiş bir yoldur, el sıkışma hatası ise denetimdir.
Sınırlar
Hız sınırları ve kotalar
Ağ geçidi kısıtlaması, API anahtarı kotası ve sağlayıcının kendi 429 yanıtı çağırana aynı görünür ama çareleri tamamen farklıdır. Yalnızca ilk ikisi bu cihazdaki ayarlardır.
Bir istek çok sık olduğu için reddediliyor ya da kota tükeniyor
Şunları görebilirsiniz: Too many requests, please try again later. (çok fazla istek; lütfen daha sonra yeniden deneyin) · Too many help requests, please try again in a few minutes. (çok fazla yardım isteği; birkaç dakika sonra yeniden deneyin) · Too many unlock requests, please try again later. (çok fazla kilit açma talebi; lütfen daha sonra yeniden deneyin) · Too many attestation requests (çok fazla doğrulama isteği)
Denetimler
- 1
Çağrıyı hangi sınırın reddettiğini belirleyin — ağ geçidinin kendi kısıtlayıcısı, bir API anahtarı kotası ya da sağlayıcınınki
beklenen · Üçünden hangisi olduğunu söyleyebiliyorsunuz.
- 2
Kota iletisi için anahtarın yapılandırılmış istek ve jeton kotalarını okuyun
beklenen · Anahtarın geçerli pencerede payı kalmış.
- 3
Redis'e erişilebildiğini denetleyin; çünkü kısıtlayıcılar sayaçlarını orada tutar
tanılama · datastores.redis.reachable = true
Nedenler ve düzeltmeler
| Ne zaman ulaşılır | Neden | Açıklama, düzeltme ve doğrulama |
|---|---|---|
| denetim 1 başarısız olduğunda | cannot-attribute (bilgi) | Bir ağ geçidi kısıtlayıcısı ile bir sağlayıcı reddi çağıranın gözünde birbirine benzer ama çözümleri bambaşkadır: biri bu cihazdaki bir ayar, diğeri sağlayıcıdaki, hiçbir CID ayarının yükseltemeyeceği bir hesap sınırıdır. Düzeltme: İsteği Olay Günlükleri içinde bulun, yolunu ve durum kodunu okuyun. Ağ geçidi kısıtlayıcısı dışarıya hiçbir çağrı yapmadan reddeder; dolayısıyla böyle bir ret için kaydedilmiş bir sağlayıcı çağrısı olmaz. Doğrulama: beklenen · Yol, hangi sınırın devreye girdiğini söylüyor. |
| denetim 2 başarısız olduğunda | key-quota-exhausted (uyarı) | Ağ geçidi API anahtarları isteğe bağlı istek ve jeton kotaları taşır ve ikisinden biri tükendiğinde anahtar reddedilir. Bu bir arıza değil, anahtara bilinçli olarak konmuş bir üst sınırdır. Düzeltme: Anahtarın kotasını yükseltin, bu iş yükü için ikinci bir anahtar çıkarın ya da pencerenin dönmesini bekleyin. Bkz. Erişim anahtarları. Doğrulama: beklenen · İstek kabul ediliyor. |
| denetim 3 başarısız olduğunda | redis-unreachable (uyarı) | Redis hem kısıtlayıcı sayaçlarını hem de zamanlanmış işleri tutar. Erişilemez olduğunda hız sınırlama kapalı değil açık biçimde zayıflar; dolayısıyla Redis kapalıyken gelen bir ret yağmuru başka bir yerden geliyordur. Düzeltme: Ağ geçidinden PostgreSQL ya da Redis'e erişilemiyor yolunu izleyin. Doğrulama: tanılama · datastores.redis.reachable = true |
Ağ geçidi API anahtarı reddediliyor
Anahtarlar özetlenerek saklanır, dolayısıyla kaybolan bir anahtar kurtarılamaz — yalnızca değiştirilir. İlginç durum grup anahtarıdır: grubun en erken eklenen üyesinin kimliğini ödünç alır, bu yüzden grubu boşaltmak anahtarın çözümlenmesini durdurur ve o üyeyi çıkarmak anahtarı iptal etmek yerine kimliğini devreder.
Ağ geçidi API anahtarı reddediliyor
Şunları görebilirsiniz: Invalid API key (API anahtarı geçersiz) · Invalid or expired API key (API anahtarı geçersiz ya da süresi dolmuş) · API key is not active (API anahtarı etkin değil) · API key has expired (API anahtarının süresi dolmuş)
Başlamadan önce
Denetimler
- 1
Anahtarı ortamda bulun
beklenen · Anahtar var.
- 2
Anahtarın durumunu ve bitiş tarihini okuyun
beklenen · Anahtar etkin ve ya bitiş tarihi yok ya da bitişi gelecekte.
- 3
Anahtarın hangi kimliğe çözümlendiğini denetleyin
beklenen · Anahtar bir kiracıya ya da en az bir üyesi olan bir gruba atanmış.
Nedenler ve düzeltmeler
| Ne zaman ulaşılır | Neden | Açıklama, düzeltme ve doğrulama |
|---|---|---|
| denetim 1 başarısız olduğunda | key-not-present (uyarı) | Anahtarlar, 32 rastgele baytın tuzsuz SHA-256 özeti olarak saklanır; dolayısıyla silinmiş ya da hiç oluşturulmamış bir anahtar tanınamaz ve veritabanından geri getirilemez. Düzeltme: Erişim Anahtarları altında yeni bir anahtar verin ve istemciyi onunla yeniden yapılandırın. Doğrulama: beklenen · Çağrı kabul ediliyor. |
| denetim 2 başarısız olduğunda | key-inactive-or-expired (uyarı) | Bir anahtar isteğe bağlı bir expires_at (NULL, hiçbir zaman demektir) ve bir etkinlik bayrağı taşır. İkisi de çağrıyı, herhangi bir yol mantığı çalışmadan önce kapıda reddeder; reddin, anahtardaki bir yazım hatasıyla birebir aynı görünmesinin nedeni budur.Düzeltme: Anahtarı yeniden etkinleştirin, bitiş tarihini uzatın ya da yerine yenisini verip istemciyi döndürün. Doğrulama: beklenen · Çağrı kabul ediliyor. |
| denetim 3 başarısız olduğunda | group-key-has-no-member (uyarı) | Grup anahtarının kendine ait bir kimliği yoktur — kimliğini gruba en önce eklenmiş üyeden ödünç alır. Grubu boşaltın ya da o üyeyi çıkarın; anahtar hiçbir kiracıya çözümlenmez ve reddedilir. Üstelik o kullanıcıyı çıkarmak anahtarı iptal etmez, kimliğini başkasına devreder. Düzeltme: Gruba bir üye ekleyin ya da anahtarı doğrudan bir kiracıya yeniden atayın. Servis kimlikleri gelene kadar bir grup anahtarını bir kişinin kimliğini taşıyor sayın. Doğrulama: beklenen · Çağrı kabul ediliyor ve oluşan kayıtlar beklenen kiracıya atfediliyor. Bu geçerli değilse: Anahtarın ön ekini (anahtarın kendisini asla), atamasını ve 401 gövdesinin tamamını ekleyin. Anahtarı bir kayda yapıştırmayın — özetinden geri getirilemediği için sızan bir anahtarın tek çaresi iptal etmektir. |
İlgili
- Kimlik Bilgileri — sağlayıcı anahtarı ekleme ve test etme.
- Modeller — katalogda ne bulunur ve nasıl doldurulur.
- Erişim anahtarları — ağ geçidi API anahtarları, kotalar ve süre dolumu.
- Ağ ön koşulları — nelere erişilebilmesi gerekir.
Son güncelleme