Proxy portu kimlik doğrulaması olmadan bağlantıya izin vermez; aksi halde adresi ve portu öğrenen herkes onu kullanabilirdi. Sağlayıcılar portun "bu bizden" demesi için iki yol sunar: bir kullanıcı adı-şifre çifti tanımlamak ya da istemcinin harici IP'sini whitelist'e eklemek. Bu yöntemler birbirinin yerine geçmez: her birinin kendine özgü bir arıza biçimi, kendine özgü bir sızıntı noktası ve ekip çalışmasında kendine özgü bir kolaylığı vardır. Hangisini kendi altyapınız için seçmeniz gerektiğine birlikte bakalım.

İki yöntem nasıl çalışır

Kullanıcı adı-şifre, bağlantı isteğinin içinde iletilir: ya proxy URL'sinde (login:password@host:port) ya da ayrı bir yetkilendirme başlığıyla. Port, isteğin nereden geldiğine bakmadan her bağlantıda çifti kontrol eder. Bu, bağlantı noktasına değil kimlik bilgilerine bağlı, klasik bir "sen kimsin" denetimidir.

IP whitelist ise farklı çalışır: port, parolasız bağlanmasına izin verilen harici adreslerin listesini önceden bilir. Burada "sen kimsin" değil "nereden geliyorsun" sorulur; proxy'ye gelen TCP isteğinin hangi IP'den geldiği kontrol edilir. İstemcinin harici adresi listedeki adresle eşleşmezse, bağlantı yetkilendirme denenmeden önce reddedilir.

IP whitelist ne zaman daha pratiktir

Whitelist, istemcinin harici adresinin sabit olduğu durumlarda zaman kazandırır: dedicated sunucu, statik IP'li ofis hattı, bulutta bir VPS. Adresi panelde bir kez eklersiniz, sonrasında her betikte parola olmadan bağlanırsınız; bu hem yapılandırmaları sadeleştirir hem de çifti yanlışlıkla depoya commit etme riskini ortadan kaldırır. Yıllarca aynı sunucudan çalışan sunucu otomasyonu için bu, en az emek gerektiren seçenektir. Whitelist'e güvenmeden önce, kanalın kendisinin istikrarlı metrikler verdiğinden emin olmakta fayda var; aksi halde adresin sabit olması, bağlantının kendisindeki bozulmayı gözden kaçırmanıza yol açabilir.

Eksisi tam olarak bir tane, ama ölümcül: sunucunun harici IP'si değişirse (hosting sağlayıcısı yeniden başlatmadan sonra yeni bir adres verdi, başka bir veri merkezine taşındınız, operatörde tarife değişti) whitelist istemciyi anında ve uyarı vermeden tanımaz hale gelir. Betik yetkilendirme hatası değil bağlantı reddi almaya başlar ve bu daha geç teşhis edilir: kod çalışıyor gibi görünür, proxy ödenmiş görünür, ama trafik akmaz.

Kullanıcı adı-şifre ne zaman zorunludur

Dinamik harici adres, whitelist'i baştan işe yaramaz kılar. DHCP ile yeniden bağlanan ev interneti, mobil erişim, her gün ağa başka bir yerden çıkan bir dizüstü bilgisayar: bu senaryolarda istemcinin IP adresi, sağlayıcının panelindeki listenin güncellenmesinden daha sık değişir. Böyle bir durumda kullanıcı adı-şifre tek işleyen yöntemdir: yetkilendirme, isteğin fiziksel olarak nereden geldiğine bağlı değildir.

İkinci durum, tek bir erişim çiftini kullanan çok sayıda makinedir. Proxy ile birkaç çalışan ya da adresleri farklı ve öngörülemez birkaç sunucu çalıştığında, her IP'yi whitelist'e elle eklemek verimsizdir; otomatik ölçeklemeli bulut altyapısında ise hiç mümkün değildir: yeni örnekler dinamik olarak yeni adresler alır. Hesapları antidetect tarayıcı üzerinden yöneten ekiplerde de benzer bir mantık geçerlidir: her çalışanın kendi profili ve kendi IP'si vardır, her biri için adresi whitelist'e sabitlemenin anlamı yoktur.

Kullanıcı adı-şifre çiftinin sızma riskleri

Kullanıcı adı-şifrenin whitelist'te bulunmayan bir zayıf noktası vardır: erişim çifti, sızabilecek bir sırdır. Hata ayıklama sırasında uygulama günlüklerine, kabuk komut geçmişine, yapılandırma yanlışlıkla commit edildiğinde herkese açık depoya, erişimi bir meslektaşınıza aktarırken yazışmalara düşer. Çifti ele geçiren kişi herhangi bir IP'den bağlanır: proxy isteğin nereden geldiğini kontrol etmez, yalnızca doğru parolayı kimin söylediğine bakar.

Bu açıdan whitelist daha dayanıklıdır: biri proxy'nin adresini ve portunu öğrense bile, kendi harici IP'sini listeye eklemeden bağlanamaz. Burada kopyalanıp götürülebilecek bir sır yoktur; yabancı birinin kontrol edemediği bir altyapıya bağlılık vardır.

Ekip çalışması için ne seçmeli

Karma yaklaşım genellikle tek bir evrensel çözümden daha isabetlidir. Sabit sunucu altyapısı için whitelist: yapılandırmalarda daha az sır, daha düşük sızıntı riski. Sürekli seyahat eden ya da evden bağlanan çalışanlar, test ortamları ve API üzerinden entegrasyonlar için kullanıcı adı-şifre, ama zorunlu rotasyonla: çift yazışmada iletildiyse ya da testte kullanıldıysa, süresiz bırakmak yerine değiştirmeniz önerilir. Belirli bir portta hangi yöntemin ve ne kadar trafik hacminde mevcut olduğunu, adres verilirken panelden kontrol edebilirsiniz.

Sıkça Sorulan Sorular

Aynı portta iki yöntemi aynı anda kullanabilir miyim?

Genellikle port, verilirken belirlenen tek bir doğrulama şemasını uygular; ancak farklı senaryolar için birden fazla port tutmanıza engel yoktur: bir kısmı sunucular için whitelist'li, bir kısmı mobil ve seyahat halindeki işler için kullanıcı adı-şifreli.

Kodda hiçbir değişiklik yapmadığım halde proxy neden birdenbire bağlantıyı reddetmeye başladı?

En sık neden, whitelist'e eklenmiş olan istemcinin harici IP'sinin değişmesidir. Sunucunun mevcut çıkış adresini kontrol edin ve panelde listelenenle karşılaştırın; hosting sağlayıcısı yeniden başlatma ya da taşıma sırasında adresi değiştirebilir.

Yapılandırmada neyi saklamak daha güvenli: parola mı, yoksa whitelist'e güvenmek mi?

Altyapı sabitse whitelist daha güvenlidir: yapılandırmada kopyalanabilecek bir sır kalmaz. İstemcinin adresi değişiyorsa kullanıcı adı-şifre kaçınılmazdır; bu durumda onu depoda açık biçimde değil, ortam değişkenlerinde ya da bir sır yöneticisinde saklamanız önerilir.

Kimlik doğrulama türünü seçip erişimi kendi altyapınıza göre proxy bölümünden oluşturabilirsiniz. Orada hangi kanalların whitelist'i desteklediği, hangilerinin yalnızca kullanıcı adı-şifreyle verildiği de görünür; bunu ilk bağlantı reddinden sonra değil, ödemeden önce kontrol etmeniz iyi olur.