Sunucuya kilitli profil bir TLS proxy arkasında başarısız oluyor: hangi nesil?

Bir kullanıcı bağlanabiliyor, diğeri bağlanamıyor; aynı portal üzerinden, aynı gün. İkisinin de sunucuya kilitli profili var, ikisi de aynı Access Server derlemesinde ve tek fark profillerinin ne zaman oluşturulduğu. Bu, tanınmaya değer bir örüntü, çünkü "sunucuya kilitli" bir bağlantı sırasını değil bir politikayı adlandırır. Access Server bu artefaktın iki neslini yayımladı ve bir TLS ters proxy yalnızca bir yolunun önünde duruyor. Hangi dalda olduğunuzu üç koşul belirler.

İki nesil, iki bağlantı sırası

2.8'e kadar geçerli olan eski tasarımda, içe aktarılan dosya bir sözde profildir. OpenVPN Connect onu HTTPS üzerinden Access Server'ın web API'sine kimlik doğrulamak için kullanır, geçici bir kullanıcıya kilitli profil ve oturum belirteci alır ve ancak ondan sonra VPN'i kurar. İki taşıma sırayla çalışır ve birincisi sıradan bir web isteğidir.

2.9 ile tanıtılan biçim, bağlantı başına bu başlatmayı yapmaz. Bu, uyumlu OpenVPN istemcilerinin kullanabildiği yerel bir profildir, yalnızca OpenVPN Connect'in değil. İndirmek veya URL ile içe aktarmak hâlâ HTTPS içerebilir — bu bir yayımlama adımıdır, bağlantı başına geçici profil çekmek değildir.

Yükseltme, zaten verilmiş profilleri zorunlu olarak yeniden yazmaz, bu yüzden güncel bir sunucu sürümü eski artefaktı hâlâ dağıtıyor olabilir. Sunucu derlemesi neyin mümkün olduğunu söyler, bu kullanıcının ne içe aktardığını değil.

Dalınızı seçen üç koşul

İlk koşul artefaktın neslidir. Dosyayı isteyin, nasıl üretildiğine bakın ve onu içe aktaran istemci sürümünü not edin. Nesli dosyadan belirleyemiyorsanız, bir test hesabı için verilen yeni profil sunucunun bugün ne ürettiğini söyler ve bu, başarısız kullanıcının elindeki bilgiden farklıdır.

İkincisi, ön ucunuzun gerçekte neyi sonlandırdığıdır. TLS'i boşaltan yedinci katman HTTP ters proxy, dördüncü katman TCP yönlendiricisiyle aynı nesne değildir; UDP yönlendiricisi de değildir. Access Server'ın 443 portundaki olağan düzeni, OpenVPN TCP arka plan programının tarayıcı trafiğini tanıyıp web servislerine vermesini sağlar, bu yüzden önüne ilgisiz bir HTTPS sonlandırıcı koymak o programın protokol işleyişini korumaz. 443 sayısını paylaşmak iki tasarımı eşdeğer yapmaz.

Üçüncüsü hatanın nereye düştüğüdür. VPN öncesi bir hata ile denetim kanalı hatası, yalnızca "bağlanıyor" diyen bir istemcide benzer görünür, ama kanıtı farklı yerlerde bırakırlar. Eski biçim işin içindeyse başlatma bir adaydır. Yeni biçim işin içindeyse boş bir web erişim günlüğü beklenir ve hiçbir yönü kanıtlamaz.

Artefakt eski olduğunda: önce başlatma başarısız olur

İstemcinin son durumunu değil gerçek hatasını okuyun. İlginç alanlar HTTPS hatası, istemcinin beklediği sunucu kimliği, isteğin gittiği hedef ve sertifika doğrulamasının tamamlanıp tamamlanmadığıdır. Ardından bunları sunucu tarafındaki web servisi ve proxy günlükleriyle karşılaştırın.

Bir tarayıcının oturum açma sayfasına ulaşması, bu istemcinin API kimlik doğrulamasının başarılı olduğunun kanıtı değildir. Bunlar farklı isteklerdir, sertifika beklentileri farklıdır ve çoğu zaman ana makine adları da farklıdır. Portal doğru sunuluyor ama istemci yine başarısız oluyorsa uyuşmazlık başlatma yolundadır, kullanıcının parolasında değil.

TLS doğrulamasını kapatarak veya kimlik doğrulama politikasını gevşeterek karşılaştırmayı geçirmeyin. Bu, teşhis edilebilir bir yapılandırma uyuşmazlığını çalışan ama doğrulanmamış bir yola çevirir ve geçici bir testi kalıcı bir deliğe dönüştüren tam da bu değişikliktir. Access Server'ın bağlantı profilleri belgeleri iki nesli ve geçici profil akışını açıklar ve proxy'nin suçlu olduğunu varsaymadan önce bakılması gereken başvuru budur.

Artefakt yeni olduğunda: bunun yerine denetim kanalını okuyun

2.9 tarzı bir profille istemci doğrudan yerel VPN uç noktasına gider. Profildeki uç noktaları, kullanılan taşımayı ve denetim kanalı hatasını inceleyin. İstemci hiç HTTP isteği göndermiyorsa bu tasarımla tutarlıdır ve belirti değildir.

Burada proxy sorusu da biçim değiştirir. HTTPS boşaltma, hiç görmediği yalnız-TCP bir akışı bozamaz, ama profili yayımlayan indirmeyi hâlâ bozabilir ve yalnız-TCP bir yönlendirici UDP'yi hiç taşımaz. Ön ucun ilgisiz olduğu sonucuna varmadan önce profilin hangi taşımayı istediğini kontrol edin.

Tek bir akış için TLS geçişi dar bir düzendir. UDP yönlendirmesi sağlamaz ve arka plan programının 443'teki kendi servis yönlendirme davranışını yeniden üretmez. Ön ucunuz bunlardan birini yapıyorsa hangisini yaptığını söyleyin, çünkü çözüm farklıdır.

Dar kalan çözümler

En az müdahaleci kontrol, bir test hesabı için yeni ve desteklenen bir profil oluşturup aynı kimlik doğrulama gereksinimleriyle amaçlanan yerel uç nokta üzerinden bağlanmaktır. Bu çalışıp saklanan eski profil çalışmıyorsa artefaktı sunucudan ve proxy'den tek adımda ayırmış olursunuz.

Kullanıcıya kilitli bir profilin dağıtımı eski başlatma bağımlılığını tamamen kaldırır, çünkü başarısız olabilecek bir geçici profil alışverişi yoktur. Amaçlanan kullanıcı için verilmelidir, asla bir yöneticiden kopyalanmamalıdır ve istemcinin ne yapmaya yetkili olduğunu değiştirir, bu yüzden ona bir geçici çözüm değil politika kararı olarak davranın.

Ardından yayımlama düzenini her gerekli yol var olacak şekilde düzeltin: indirmeler ve portal kullanımı için web yolu ve profillerin beklediği taşımada yerel VPN yolu. Proxy'nin işini tek katmanda tutun. Çalışan, kullanıcıya kilitli bir tünel o yolun çalıştığını kanıtlar; her proxy düzeninin her nesli desteklediğini kanıtlamaz ve eski bir başlatma hatası daha yeni biçimi mahkûm etmez.

• Proxy'ye dokunmadan önce artefaktın neslini belirleyin.
• Hatanın tünelden önce mi yoksa içinde mi oluştuğunu belirleyin.
• Ön ucun neyi sonlandırdığını doğrulayın: HTTP, TCP akışı veya UDP.
• Yeni verilmiş bir profili politika değişmeden yerel uç noktaya karşı test edin.