AWS Client VPN: giriş başarılı ama alt ağa erişilemiyor
Başarılı bir AWS Client VPN girişi her alt ağa yetki vermez. Erişimi genişletmeden önce grup değerini ve en özel hedef kuralını kontrol edin.
İstemciniz Connected diyor, sertifika geçerli ve intranet sayfası yine de zaman aşımına uğruyor. Bu fark neredeyse hiçbir zaman kimlik doğrulama değildir. AWS Client VPN hedefleri girişten ayrı olarak yetkilendirir ve iki yaygın neden, kimlik sağlayıcısının gönderdiğiyle eşleşmeyen bir grup değeri ile geniş kuralı yenen daha özel bir hedef kuralıdır. İkisi de nereye bakacağınızı bildiğinizde endpoint yapılandırmasında görünür.
Giriş başarılı oldu; kural eşleşmedi
Kimlik doğrulama kullanıcının kim olduğunu yanıtlar. Yetkilendirme kuralları bu kimliğin hangi ağ öneklerine erişebileceğini yanıtlar. Kullanıcı ilkini geçip ikincisinde başarısız olabilir ve istemci size her istek zaman aşımına uğrarken ayakta kalan bir bağlantıdan fazlasını vermez.
Endpointin hedefi başarısız adresi içeren bir yetkilendirme kuralına sahip olduğunu doğrulayarak başlayın. Eşleşen kural yoksa bağlantı doğru davranıyordur; eksik olan ilkedir.
Grup değeri gerçekte nereden geliyor
Active Directory'de access-group alanı grubun görünen adını değil SID'sini tutar. SAML federasyonunda, yapılandırılmış SAML grup özniteliğinin gerçekte taşıdığı grup kimliğini veya adını tutar. Değeri assertion'dan veya dizin sorgusundan kopyalayın, bir wiki sayfasından değil.
IAM grubu farklı bir denetim düzlemidir. Bir Client VPN endpointini yönetme izni, bir IAM grubunu kullanıcının VPN grubu yapmaz ve bir IAM grup adını access-group alanına yapıştırmak onu AD SID'sine veya SAML öznitelik değerine çevirmez.
Başka bir dizinde benzer adlı bir grup hiçbir şey kanıtlamaz. Endpointin kimlik doğrulama yöntemini ve kullanıcının aynı sistemdeki üyeliğini veya assertion'ını kontrol edin.
En uzun önek kazanır, 0.0.0.0/0 dahil
Yetkilendirme en uzun önek eşleşmesine göre değerlendirilir ve tüm hedefler kuralı ilk değil son olarak değerlendirilir. Engineering için 10.46.0.0/16 kuralı ve herkes için 0.0.0.0/0 kuralı ekleyin; Engineering dışındaki bir kullanıcı geniş kural üzerinden 10.46.20.10 adresine yine ulaşamaz.
İşte burada bir düzeltme ters gidebilir. Dar kuralı silmek kullanıcının erişimini geri getirir ve o alt ağı geniş kuralın kapsadığı her kimliğe de verir. Herhangi bir şeyi silmeden önce grup-ağ matrisini kurun ve hangi grupların hangi aralığa ulaşması gerektiğini yazın. Bu kurallar yalnızca izin verir; geniş bir izinden istisna kesmek için bir ret girdisi yoktur.
Değişikliklerin adil değerlendirilmesi için taze bir bağlantı da gerekir. Kuralları düzenledikten sonra istemciyi yeniden bağlayın, sonra tekrar test edin.
Yetkilendirmeyi veri yolundan ayırın
Eşleşen kural bir yol değildir. Endpointin ilişkili bir alt ağa ve hedef için yönlendirme tablosu girdisine ihtiyacı vardır ve hedef kaynağın güvenlik grubu trafiği kabul etmelidir. Dönüş trafiği ve DNS de çalışmalıdır.
Başarılı olması gereken bir kullanıcıyı ve dışarıda kalması gereken bir kullanıcıyı test edin. İkisi de giriş yapabilir ama yalnızca biri alt ağa ulaşır ve istediğiniz kanıt o farktır.
Bir IP adresi çalışıp ana makine adı çalışmıyorsa, yetkilendirmeye dokunmadan önce resolver'a bakın. Hiçbir yol adresi kapsamıyorsa ilişkilendirmeyi veya yönlendirme tablosunu düzeltin. Paket gelip hizmet reddediyorsa sıradaki durak o hizmetin ilkesidir. Yetkilendirme matrisini tüm kullanıcılara genişletmek, katmanlardan hangisinin gerçekten bozuk olduğunu gizler.
Ticket'ı kapatmadan önce kimlik kaynağını, tam grup değerini, hedef öneklerini ve trafiği taşıyan yolu kaydedin. Bu not, bir sonraki bağlandı ama erişim yok bildirimini bir tur daha tahmin yerine iki dakikalık bir karşılaştırmaya dönüştürür.