Port-Share neden tüm web sitesi ziyaretçilerini localhost gibi gösteriyor

Erişim günlüğündeki her satır aynı loopback adresini gösteriyor, oysa sayfa kendisi yükleniyor ve sertifika doğru şekilde doğrulanıyor. Erişilemezlik anlamında hiçbir şey bozuk değil ve bu yüzden bu durum aylarca sürüyor. Bozulan şey atıftır: web arka ucu bağlantıyı ileten atlamanın adresini kaydeder ve günlüğe güvenen her sonraki karar aynı yanlış yanıtı devraldı.

Aşağıdaki kontroller kablodan içeri doğru ilerler. Gördüğünüz değeri açıklayan ilk kontrolde durun, çünkü her sonraki adım öncekilerin zaten doğru olduğunu varsayar. Hiçbiri ön uç yapılandırmasını tahmin etmenizi gerektirmez.

Günlük satırını değil, iki bağlantıyı izleyin

Port-Share iki protokolü tek bir TCP dinleyicisinde çoğullar. OpenVPN gelen bağlantının ilk baytlarını inceler, kendi protokolüne benziyorsa onu tutar ve geri kalan her şeyi ikinci bir hedefe verir. Bu hedef genellikle aynı ana makinedeki bir web sunucusudur, bu yüzden web sunucusunun kabul ettiği soketin eşi OpenVPN sürecidir.

ss -ltnp 'sport = :443'
ss -tnp 'dport = :8080'

İlk komut genel dinleyicinin kime ait olduğunu gösterir. İkincisi arka uç bağlantı noktasına gelen bağlantıları gösterir ve bunların eş adresi erişim günlüğünün yazdıracağı adrestir. Bu eş loopback ise günlük doğrudur ve bilgi bir katman önce kaybolmuştur. Günlük alanını yeniden adlandırmak veya bir istemci IP modülünü etkinleştirmek, bağlantının hiç taşımadığı bir adresi geri getirmez.

Diğer her şeye karar veren kontrol budur. Arka ucun eşi tarayıcının adresi ise bağlantı noktası paylaşımı sizin sorununuz değildir ve günlük biçimidir.

Taşıma iletimi başlık enjeksiyonu değildir

İletici baytları taşır. HTTP'yi ayrıştırmaz, bu yüzden hiç istek olarak okumadığı bir isteğe başlık ekleyemez ve dokunmadan geçirdiği bir TLS akışına hiçbir şey ekleyemez. Proxy başlığı bekleyen bir modül, hiçbir bileşenin üretmediği bir başlığı beklemeye devam eder.

Orijinal adresi iki mekanizma taşıyabilir ve ikisi de iki uçta anlaşma gerektirir. PROXY protokolü bağlantının başına küçük bir başlık ekler ve arka uç bunu bekleyecek şekilde yapılandırılmalıdır; beklemeyen bir arka uç bu baytları isteğin başlangıcı sayar ve kafa karıştırıcı biçimde başarısız olur. X-Forwarded-For gibi güvenilir proxy başlıkları, HTTP anlayan bir proxy bunları ayarladığında ve arka uca hangi eşlerin bunları iddia edebileceği söylendiğinde çalışır.

İkisi de otomatik değildir ve ikisi de varsayılan olarak güvenli değildir. Gelen her iletilen başlığa inanan bir arka uç, istemcinin kendi adresini seçmesine izin verir; bu da günlükteki bir yanlışlığı erişim denetimini atlatmaya dönüştürür. Üretim yolunda herhangi bir başlığa güvenmeden önce gösterimi bir kez test ana makinesinde çalıştırın.

curl -sS -H 'X-Forwarded-For: 127.0.0.1' https://site.example.com/health
grep -F '127.0.0.1' /var/log/nginx/access.log | tail -n 3

İsteğe bağlı kaynak eşleme dizini

Bağlantı noktası paylaşımının, özelliğin uygulandığı platformlarda orijinal kaynak adresi ile iletme bağlantısı arasında eşleme kaydeden isteğe bağlı bir dizin bağımsız değişkeni vardır. Web tarafının bu eşlemeye başvurması beklenir; bu bir başlık değildir ve isteğe enjekte edilmez.

Bu tasarım bilinmeye değer, çünkü görünüşte aynı ön uç yapılandırmasıyla bazı kurulumların gerçek adresler bildirdiğini, bazılarının bildirmediğini açıklar. Fark alıcı taraftadır ve genellikle paketlenmiş web sunucularının çoğunun varsayılan olarak etkinleştirmediği bir modülde veya yamada yaşar. Web sunucunuzun belgelerinde sunduğu tam kancayı okuyun ve modülün yüklendiğini varsaymak yerine doğrulayın.

Bu yolu seçerseniz, iki yarıdan oluşan bir entegrasyon olarak ele alın: ileticinin yazdığı eşleme ve arka ucun yaptığı arama. İkisini de doğrulayın ve dizinin yeniden başlatmaya dayandığını ve yoğun bir dinleyicide sınırsız büyümediğini doğrulayın.

Adrese hangi bileşenin kefil olduğuna karar verin

Yapılandırmayı değiştirmeden önce, bir istemci adresini iddia etmesine izin verilen bileşeni ve ona inanmasına izin verilen bileşenleri adlandırın. Tek bir yazılı yanıt, üç farklı katmanın her birinin farklı bir kaynağa güvendiği olağan kaymayı önler.

Üç tasarım çoğu ihtiyacı karşılar. Genel dinleyiciyi ve web dinleyicisini ayrı tutun, böylece web sunucusu gerçek eşleri görsün ve atıf sorunu oluşmasın. Önüne HTTP anlayan bir ters proxy koyun, isteği orada sonlandırın veya ayrıştırın ve yalnızca o proxy'ye güvenen bir arka uç için iletilen başlığı ayarlamasına izin verin. Ya da bağlantı noktası paylaşımını koruyun ve günlüklerin atlamayı gösterdiğini kabul edin; erişim kuralları adrese değil, uygulama kimliğine göre yazılır.

İşe yaramayan şey, iletilen bir loopback adresini isteğin bu makinede oluştuğunun kanıtı saymaktır. Bu çıkarım tam tersidir: adres, tam da yerel bir bileşen bağlantıyı kurduğu için vardır. Böyle yazılmış bir kural dinleyiciye ulaşabilen herkesi kabul eder.

Sayfayı değil kuralı test edin

Yüklenen bir sayfa iletme yolunun çalıştığını kanıtlar ve atıf hakkında hiçbir şey söylemez. Adresin tüketicisini test edin: erişim kuralını, hız sınırını, denetim kaydını, coğrafi aramayı.

curl -sS -o /dev/null -w '%{http_code}\n' https://site.example.com/
tail -n 5 /var/log/nginx/access.log
grep -c '' /var/log/nginx/access.log

Yetkili bir dış isteği hem ön uç hem de arka uç kayıtlarıyla karşılaştırın ve reddetmesi gereken kuralın hâlâ reddettiğini, izin vermesi gerekenin hâlâ izin verdiğini doğrulayın. Günlük satırı doğruysa ama kural hâlâ herkesi yerel sayıyormuş gibi davranıyorsa, kural sizin düzelttiğinizden farklı bir alanı okuyordur.

Dağıtım notlarına atıf zincirini yazarak bitirin: hangi dinleyici, hangi iletici, hangi başlık veya eşleme ve hangi arka ucun ona güvenmek üzere yapılandırıldığı. Günlük satırını okuyacak sonraki kişi dördüne de ihtiyaç duyacak ve o notun yokluğu aynı biletin bir yıl sonra yeniden açılmasının nedenidir. Onu sohbet dizisinde değil, yapılandırmanın yanında tutun.