HAProxy 302 özel bir uygulamaya: ikinci atlamayı kim açar?

Birisi genel bir HAProxy ana bilgisayarını şirket içi bir uygulamaya yöneltir ve tarayıcının neden izleyemediğini sorar. Proxy uygulamaya kendi VPN'i üzerinden ulaşır, yönlendirme bir Location başlığı döndürür ve tarayıcı ardından yalnızca tünelin içinde var olan bir adresi dener. Dışarıdan bakıldığında sayfa yalnızca askıda kalır. Karar, ikinci bağlantıyı hangi tarafın açtığıyla ilgilidir ve bir yönlendirmeyi bir arka uçtan ayıran da budur.

Yapılandırmada birbirine benzeyen iki yol

Bir yönlendirme alışverişi bir yanıtla bitirir. İstemci Location'ı okur ve bulunduğu yerden yeni bir istek başlatır; bu, hiç denetlemediğiniz ağdır. Proxy artık işin içinde değildir. Sonraki her şey istemcinin kendi DNS'ine, rotasına ve güvenine bağlıdır, dolayısıyla sonuç kullanıcının tarayıcıyı nerede açtığına göre değişir:

GET /app        client -> proxy
302 Location    proxy  -> client   (http://10.40.0.20:8080/)
GET /app        client -> 10.40.0.20:8080   client network, no route

Bir proxy arka ucu ikinci ayağı sunucu tarafında tutar. Proxy onu zaten sahip olduğu yol üzerinden açar ve istemci tek bir genel adla konuşmaya devam eder. Tünel düşerse istemci, izleyemeyeceği bir URL yerine bir hata alır. Bu fark aynı zamanda arızayı teşhis edilebilir kılan şeydir, çünkü hata günlüklerin bulunduğu yerde görünür:

GET /app        client -> proxy
GET /app        proxy  -> 10.40.0.20:8080   over the VPN
response        proxy  -> client

HAProxy'nin yönlendirme belgeleri tam bu çizgiyi çizer: istemciye bir yönlendirmeyle yanıt vermek, isteği bir arka uca iletmekten farklı bir eylemdir. İki yönerge bir yapılandırma dosyasında birkaç satır arayla durur ve hiç benzemez. Biri isteği bitirir, diğeri proxy'nin sahip olduğu ikinci bir isteği başlatır.

Tarayıcının ihtiyaç duyduğu ama sunucunun VPN'inin vermediği şey

Tarayıcının kendi isteği, sahip olmayabileceği dört şeye ihtiyaç duyar: özel ad için bir DNS yanıtı, o adrese bir rota, dinleyen hizmete ulaşma izni ve o hizmetin sunduğu sertifikaya duyulan güven. Proxy ana bilgisayarı dördüne de tüneli sayesinde sahiptir. Hiçbiri o tünelde hiç bulunmamış bir istemciye geçmez, çünkü tünel URL'nin değil ana bilgisayarın bir özelliğidir.

Bu boşluk «neredeyse çalışıyor» belirtisini açıklar. İlk istek başarılı olur, adres çubuğu değişir ve proxy baştan sona sağlıklıyken bağlantı sonra askıda kalır ya da başarısız olur. Proxy yapılandırmasında hiçbir şey bozuk değildir ve onu ayarlamak 10.40.0.20'ye yolu olmayan bir istemciye yardım edemez. Ya istemci bir rota alır ya da proxy bağlantıyı onun adına kurmak zorundadır.

Uygulamaya yalnızca proxy ulaşabildiğinde

Yönlendirme eylemini kaldırın ve bu istekleri özel adrese işaret eden bir arka uca gönderin. Ön uç genel adını korurken arka uç isteğin gerçekte nereye gittiğine karar verir. İstemcinin yolunda hiçbir şey değişmez, çünkü proxy bir hedefi tanımlamayı bırakıp hedefin kendisi olur. Dahili 8080 bağlantı noktasını bilerek dinleyen bir uygulama için sunucu bloğu kısadır:

backend private_app
    mode http
    option httpchk GET /health
    server app1 10.40.0.20:8080 check

O bloğu proxy'nin yönlendirme tablosu hakkında bir ifade olarak okuyun: 10.40.0.20'ye proxy ana bilgisayarının kendisinden ulaşılabilmelidir; bu burada varsayılan rota üzerinden değil VPN arayüzü üzerinden anlamına gelir. check anahtar sözcüğü yalnızca o rotanın ne yaptığını bildirir ve sağlık yolu uygulamada var olmalıdır, yoksa her yoklama sunucuyu kapalı olarak işaretler. Geçen bir kontrol istemci hakkında hiçbir şey kanıtlamaz ve arka ucu kimin kullanabileceğine karar veren politikayı değiştirmez.

Bu parça tam bir ön uç değildir. Dinleyiciyi, kimlik doğrulamayı, izin verilen ana bilgisayar ve yol seçimini ve uygulamaya kimin erişebileceğine karar veren kuralı koruyun. Arka uç protokolünü de eşleyin, çünkü bir HTTPS arka ucu sertifika doğrulaması ve sunucu kimliği yapılandırması gerektirir ve bu kontrolü atlamak özel bir bağlantıyı doğrulanmamış bir bağlantıya dönüştürür.

Zafer ilan etmeden önce dönüş yolunu iki yönde de doğrulayın. Uygulama artık proxy'den gelen bir bağlantı görür, dolayısıyla günlükleri ve istemci adresiyle ilgili tüm üst veriler, aksini düzenlemediğiniz sürece proxy'yi tanımlar. Kimliğin ve iletilen adreslerin nasıl işleneceğine karar verin ve bu kararı varsaymak yerine test edin.

Uygulamanın kendi yönlendirmeleri hâlâ içeriye işaret ediyor

İlk isteği iletmek entegrasyonun yalnızca yarısıdır. Uygulama mutlak yönlendirmeler, sabit kodlanmış varlık URL'leri veya içeride bildiği ada kapsanmış çerezler üretebilir ve bunların her biri tarayıcıyı ulaşamayacağı bir adrese geri gönderir. Dahili ada işaret eden bir Location başlığı özgün sorunla tamamen aynı görünür, bu yüzden bir proxy arızası olarak yanlış teşhis edilir.

Uygulamanın belgelenmiş dış URL'sini ve proxy seçeneklerini ayarlayın, ardından Host başlığını sanal ana bilgisayar ve sertifika beklentileriyle uyumlu hale getirin. Dahili ada kapsanmış bir çerez genel ad üzerinden geri gelmez ve ardından gelen oturum açma döngüsü bir kimlik doğrulama hatası olarak okunur. Önce dış URL'yi değiştirin, temiz bir tarayıcı profilinden yeniden test edin ve yarı taşınmış ayarların başarılı olan bir giriş ile hemen ölen bir oturum üreteceğini bekleyin.

İletilen üst verilere yalnızca belirlenmiş proxy'den güvenin. Herhangi bir istemcinin ayarlayabildiği bir başlık asla bir yetkilendirme değeri olmamalıdır, yoksa proxy bir çağıranın başkasının kimliğine bürünmesinin yoluna dönüşür. Bu kural yönlendirme sorusundan bağımsızdır ve sonraki her yeniden tasarımda geçerliliğini korur.

Gerçekte hangi tasarıma sahip olduğunuza karar verin

Tüm kullanıcıların zaten yetkili VPN erişimi varsa, özel bir URL'ye yönlendirme bilinçli bir tasarım olabilir. Bu gereksinimi varsaymak yerine açıkça doğrulayın, çünkü iki tasarım tamamen farklı kitlelere hizmet eder. Biri otel ağından hiç çalışmaz, diğeri ise uygulamayı genel URL'yi yükleyebilen herkese açar. Bu ayrım tasarım notunda yer almalıdır.

Kontrolü kullanıcıların ağındaki bir makineden çalıştırın ve tarayıcının yaptığı her atlamayı izleyin, yalnızca ilk yanıtı değil. Adres çubuğunu ve sonraki her isteği göz önünde bulundurun, çünkü bir varlık etiketindeki tek bir mutlak URL ilk atlamayı geçen bir akışı bozmaya yeter. Oturum açma genel ad üzerinden çalışmalı ve reddedilmesi gereken kaynaklar reddedilmiş kalmalıdır.

Ters proxy yayınlamak ayrı bir erişim kararıdır, proxy'nin kendi VPN'inin genel URL'sini yükleyebilen herkese şeffaf biçimde uzatılması değildir. Bir diyagramda ikisi benzer görünür ve kimin içeri alındığı konusunda ayrılırlar. Bu soruya dağıtımdan sonra karar vermek, dahili bir uygulamanın kazara genel bir uygulamaya dönüşmesinin yoludur.

Hangisini inşa ettiğinizi ve nedenini yazın. Yapılandırmaya dokunacak bir sonraki kişi diğerini varsayacaktır. Kolaylık olsun diye eklenen tek bir yönlendirme, özgün arızayı yeniden yaratmaya yeter ve belirti tam olarak az önce düzelttiğinize benzeyecektir.