URL'nizin neden 45000 değil, 80 veya 443 portunda bir girişe ihtiyacı var

Bir tarayıcıya ana makine adı yazın ve şema hedef portu belirler: http için 80, https için 443. DNS yanıtındaki hiçbir şey bunu geçersiz kılmaz ve makinenizdeki hiçbir yönlendirme kuralı sağlayıcının kenarında bir dinleyici uyduramaz. Bir VPN sağlayıcısı size 45000 gibi yüksek bir genel port verdiğinde, açık bir URL çalışır, temiz olan çalışmaz. Boşluk giriş noktasında, uygulamanın içinde değil.

Tarayıcıdan sürece giden yolu bir kez izleyin, üç yayınlama seçeneği artık gizemli görünmeyecek.

İsteğin gerçekte nereye gittiğine bakın

Tarayıcı adı bir adrese çözer, ardından URL başka bir port belirtmiyorsa şemanın varsayılan portunda o adrese bağlanır. Gelen bağlantıya ne olacağını sağlayıcınızın kenarı belirler. Yönlendirme tablosu yalnızca 45000'i iç adresinize eşliyorsa, 80'e giden bağlantının gidecek yeri yoktur ve makineniz devreye girmeden önce reddedilir veya düşürülür.

Bu ret kenarda gerçekleşir, bu yüzden uygulamanızın günlükleri hiçbir şey göstermez. Günlüklerin yokluğu paketin nerede durduğuna dair kanıttır, uygulamanın bozuk olduğuna dair değil.

Yerel bir kural kenarı neden düzeltemez

Uygulama ana makinesindeki bir yönlendirme veya DNAT kuralı, zaten gelmiş paketler üzerinde etkilidir. Sağlayıcıda 80 portuna gönderilen paketler hiçbir zaman ulaşmaz, bu nedenle kural hiçbir zaman değerlendirilmez. Bu, tüm sorundaki en yaygın boşa harcanan saattir.

DNS de portu taşıyamaz. HTTP belirtimi şemanın varsayılanlarını tanımlar; A veya AAAA kaydı bir adres döndürürken CNAME başka bir ad döndürür. Tarayıcı yine de şemanın portunu ekler, bu nedenle hedefi yalnızca URL'deki açık bir port değiştirir.

Birinci seçenek: açık portu korumak

Çoğu zaman doğru cevap gösterişsiz olandır. Tam URL'yi portla birlikte yayınlayın, TLS'i bunu destekleyen bir girişte sonlandırın ve oluşturulan her bağlantının aynı kökeni koruduğundan emin olun. Küçük ve kontrollü bir kitle için bu yeterlidir ve görünür bir port numarası dışında hiçbir maliyeti yoktur.

Oradayken yönlendirmeleri ve çerez kapsamını kontrol edin, çünkü kendi ana makine adını Location başlığına yazan bir arka uç bu düzenlemeyi bozar.

İkinci seçenek: varsayılan portta gerçek bir giriş edinmek

Bazı sağlayıcılar ve barındırma düzenleri, belgelenmiş bir hizmet olarak paylaşılan veya özel bir adreste 80 ve 443'ü iletir. Genel bir çıkış adresinin keyfi gelen portlar anlamına geldiğini varsaymak yerine gerçekte nelerin dahil olduğunu sorun. Özel bir çıkış adresi gelen yönlendirme hakkında hiçbir şey söylemez.

Sahiplik ve kullanılabilirliği yazılı olarak doğrulayın; tünel farklı bir adresle yeniden bağlandığında girişe ne olacağı da buna dahil. Tünelle birlikte hareket eden bir giriş, DNS arızaları gibi görünen kesintiler üretir.

Üçüncü seçenek: önüne bir ön uç koymak

Erişilebilir bir adresteki ters vekil, 443'te dinlemek ve TLS'i sonlandırmak ve VPN üzerinden arka uca ayrı bir bağlantı açabilir. Ziyaretçiler ön ucun adını ve varsayılan portunu görürken, ön uç sizin adınıza arka ucun yüksek portuyla konuşur. Bu işe yarar çünkü giriş noktasıyla savaşmak yerine mimariyi değiştirir. Arka uç o zaman genel internette gelen porta hiç ihtiyaç duymaz.

Ayrıca işlettiğiniz şeyi de değiştirir. Ön uç genel TLS'in, erişim ilkesinin, günlüklerin ve kullanılabilirliğin sahibidir ve arka uç seçimini amaçlanan hizmetle sınırlamalıdır. Ön uçtan arka uca geçiş HTTPS kullanıyorsa, o geçişte sertifika doğrulamasını koruyun.

Tek bir köken koruyun

Ön ucun genel ana makine adı, şeması ve portu ziyaretçilerin kullandığı kökeni oluşturur, bu nedenle uygulamanın dış URL'sini, yönlendirmeleri ve çerezleri o köken için yapılandırın. Uygulama mutlak bağlantılar kuruyorsa orijinal ana makineyi ve iletilen şemayı gönderin. Kullanıcıları özel bir ada veya yüksek bir porta geri gönderen bir yanıt, az önce kurduğunuz temiz girişi bozar.

Sonra kitleyi göz önünde bulundurarak karar verin. Kısa bir URL yönetilen bir ön ucu haklı çıkarabilir ve yalnızca VPN için olan özel bir hizmeti yanlışlıkla genel bir hizmete dönüştürmeye değmez.