Bir VPN oturum açma isteği RADIUS'a ve kimlik sağlayıcınıza nasıl ulaşır
Bir VPN oturum açmayı istemciden ağ geçidinin RADIUS isteğine, arkasındaki kimlik sağlayıcıya ve kabulden sonra uygulanan politikaya kadar izleyin.
Geçen hafta bir kullanıcı VPN'e giriş yapabildi ama yine de hiçbir şeyin çözülemediği bir ağa düştü. İstemci bağlı dedi, ağ geçidi günlüğü Access-Accept dedi ve kimlik ekibi hesabın iyi olduğunu söyledi. Oturum açma çalışmıştı; arkasındaki yetkilendirme çalışmamıştı. Bir VPN oturum açma başarısız olduğunda, isteğin gerçekte izlediği yolu izlerim — istemci, ağ geçidi, RADIUS sunucusu, kimlik sağlayıcı — ve yanıtı bir sonrakiyle uyuşmayan ilk adımda dururum.
İstemci asla RADIUS konuşmaz
Dizüstü bilgisayardaki uygulama ne gösterirse göstersin, ilk adımı VPN protokolüdür: IKEv2, OpenVPN, WireGuard veya TLS tabanlı bir istemci. RADIUS bu alışverişte görünmez. İstemci ağ geçidine sertifika, kullanıcı adı ve parola veya tünel kurulumunda taşınan bir EAP yöntemiyle kimlik doğrular.
Bu, günlükleri okurken önemlidir, çünkü kullanıcının gördüğü genel kimlik doğrulama hatasını ağ geçidi, başka bir şeyle zaten konuştuktan sonra üretir. İstemci ağ geçidine hiç ulaşmazsa, hata ayıklanacak bir RADIUS isteği yoktur ve RADIUS sunucusunda geçirilen bir saat boşa gider. Arka uca dokunmadan önce tünelin gerçekten kurulduğunu doğrulayın.
Ağ geçidi RADIUS istemcisidir
Tünel kurulumu kimlik bilgilerinin kontrol edilmesi gereken noktaya ulaştığında, ağ geçidi bir ağ erişim sunucusu olur. Bir Access-Request oluşturur: User-Name, parola veya EAP yükü, NAS-IP-Address veya NAS-Identifier ve yöntem gerektirdiğinde Message-Authenticator. İstek varsayılan olarak UDP 1812'ye, muhasebe ise 1813'e gider. Eski kurulumlar hâlâ 1645 ve 1646 kullanır, bu yüzden bir çift için yazılmış güvenlik duvarı kuralı birçok sessiz hatayı açıklar.
İki taraf bir sır paylaşır ve bu kullanıcı kimlik bilgisi değildir. Alışverişi imzalar ve her yanıt ona göre doğrulanır. Sırrı iki tarafta farklı yapılandırın, sunucu yanlış sır diye yanıt vermez — isteği düşürür veya yanıt doğrulamadan geçmez, böylece ağ geçidi zaman aşımı bildirir. Yanlış sır ve ölü sunucu ağ geçidinden aynı görünür, bu yüzden dizini suçlamadan önce adımı bir istemci aracıyla test ederim.
Protokol küçük ve eskidir — RFC 2865 kimlik doğrulama alışverişini tanımlar — ancak taşıdığı öznitelikler VPN politikasının çoğunun üzerine kurulduğu temeldir.
# ask the RADIUS server directly, from the gateway host
radtest alice 'test-password' 127.0.0.1 0 testing123
# watch the exchange the gateway actually sends
tcpdump -ni any -c 20 'udp port 1812'RADIUS sunucusu yalnızca kimlik sağlayıcının ön yüzü olabilir
İnsanlar RADIUS ve kimlik sağlayıcıdan aynı kutuymuş gibi söz eder. Çoğu zaman değildir. RADIUS sunucusu Access-Request'i alır ve yanıtlamadan önce başka bir şeye sorar — LDAP veya Kerberos üzerinden Active Directory, yerel bir kullanıcı dosyası veya harici bir hizmet. LDAP veya krb5 modüllü FreeRADIUS, Windows NPS ve Cisco ISE hepsi bu konumdadır.
Fark, nereye bakacağınızı belirler. Reddedilen parola, RADIUS'un ilettiği kimlik sağlayıcı yanıtıdır. Zaman aşımı genellikle RADIUS-kütüphane arasındaki bölümdür: süresi dolmuş bind hesabı, erişilemeyen dizin veya yanlış arka uca yönlendirilmiş istek. Kullanıcı adında alan adı soneki varsa, sunucu buna göre yönlendirebilir ve CORP\alice ile [email protected] olarak gönderilen aynı hesap farklı yerlere düşebilir. Windows NPS'te Security günlüğü izin için 6272, ret için 6273 kaydeder; bu da kararın NPS'ten gelip gelmediğini söyler.
Hatayı onu üreten adımda okuyun
Tek bir bağlanılamıyor iletisi dört farklı hatayı kapsar. Bir şeyi değiştirmeden önce belirtiyi onu üreten adımla eşleştirin.
| What you see | Where it comes from | First check |
|---|---|---|
| Gateway timeout, no reply | Shared secret mismatch, UDP 1812 blocked, unknown NAS, wrong server address | tcpdump at the gateway; radtest from the gateway host |
| Immediate reject | Credentials, account state, domain suffix, RADIUS policy | NPS 6273 or the FreeRADIUS auth log; test the account directly |
| Repeated challenge or MFA loop | Access-Challenge state not returned, or a token that expired mid-flow | Client prompt timing and the State attribute in debug output |
| Accept, then no access | Authorization attributes unmapped, wrong pool, route or ACL policy | Gateway policy and the attributes in the Access-Accept |
İnsanları yanlış ekibe gönderen son satırdır. Access-Accept kimlik bilgilerinin kabul edildiği anlamına gelir; ağ geçidinin kullanıcıyı doğru havuza koyduğu veya rotaları ittiği anlamına gelmez. Grup öznitelikleri yalnızca ağ geçidi politikası onları okursa önemlidir. Doğru bir oturum açmanın misafir havuzuna düştüğünü gördüm, çünkü grup eşlemesi RADIUS tarafında ağ geçidinin incelediğinden farklı bir öznitelik için yapılandırılmıştı.
Bir oturum açmayı baştan sona izleyin
Tek bir test hesabı ve tek bir ağ geçidi seçin, sonra aynı denemeyi dört noktada gözlemleyin. RADIUS tarafında hata ayıklama çalıştırın — freeradius -X isteği ve dokunduğu her modülü yazdırır — ağ geçidinin kimlik doğrulama günlüğünü izleyin ve UDP alışverişi için tcpdump çalıştırın. Bir kez bağlanın ve dört izi sırayla okuyun.
Görmek istediğiniz şey uyumdur: ağ geçidi beklediğiniz kullanıcıyı sordu, RADIUS sunucusu beklediğiniz arka ucu seçti, o arka uç bir karar döndürdü ve yanıttaki öznitelikler ağ geçidinin uyguladığı politikayla eşleşiyor. İzlerin ilk ayrıştığı yer sizin hata sınırınızdır. Yanıt bir grup özniteliği taşımıyorsa sorun VPN profilinde değil RADIUS tarafındadır; öznitelik varsa ve ağ geçidi onu yok sayıyorsa sorun ağ geçidi politikasıdır.
Oradayken bir güvenlik notu. Paylaşılan sır alışverişi korur ama özniteliklerin çoğunu şifrelemez. Ağ geçidi ile RADIUS sunucusu farklı segmentlerdeyse o adımı TLS üzerinden RADIUS'a veya özel bir yola koyun. Şifrelenmiş kullanıcı tüneli arka uç bağlantısı hakkında hiçbir şey söylemez.
Bileti kapatmadan önce dört şeyi doğrulayın. Ağ geçidi RADIUS sunucusuna gerçekten yapılandırıldığı bağlantı noktasından ulaşabilir. Paylaşılan sır iki tarafta eşleşir. RADIUS sunucusu ağ geçidinin gönderdiği kullanıcı adının tam biçimini çözer. Kabul, ağ geçidi politikasının ihtiyaç duyduğu öznitelikleri taşır. Dördü de doğruysa, hâlâ başarısız olan bir oturum açma kimlik doğrulama değil ağ geçidi politikası sorunudur.