GitHub Proxy: Klonlama, Varlık Trafiği ve Cihaz Senkronizasyonu

DNS ve WebRTC sızıntısı geliştirici tarafında neyi açık eder?

Proxy tanımlamak, alan adı çözümünün de proxy üzerinden yapıldığı anlamına gelmez. İstemci alan adını yerel çözümleyiciyle çözüp yalnızca bağlantıyı proxy’ye verirse, hangi ana bilgisayarlara gittiğiniz ağ sağlayıcınıza görünür. Geliştirici tarafında bu, sıradan bir gizlilik sorunundan fazlasıdır: kurum içi bir GitHub örneğinin alt alan adı çoğu zaman şirket adını taşır ve çözümleme kaydı bu ismi açık eder.

Şifreli bağlantılarda da alan adı el sıkışma sırasında sunucu adı göstergesiyle taşınabilir. İçerik okunamaz, ancak nereye bağlandığınız yol üzerindeki bir gözlemciye görünebilir. Bu yüzden proxy seçerken çözümlemenin nerede yapıldığı, en az çıkış adresinin kendisi kadar önemlidir. SOCKS5’te çözümlemenin istemcide mi uzak uçta mı yapıldığı ayarlanabilir; ayrıntısı SOCKS5’te DNS nerede çözülür yazısında.

Tarayıcı tarafında ikinci risk WebRTC arayüzüdür. Bir sayfa bu arayüz üzerinden gerçek yerel ve genel adresinizi öğrenebilir. Proxy yalnızca HTTP trafiğini yönlendiriyorsa bu kanal açık kalır ve dikkatle kurduğunuz çıkış görünümü tek bir sorguyla anlamsızlaşır.

Kurulumdan sonra üç aracı sırayla çalıştırın: DNS leak testi, WebRTC leak testi ve anonimlik testi. Üçü de temizse kapsamınız gerçekten kapalı demektir.

Bu testleri yalnızca kurulum gününde değil, ağ tarafında bir şey değiştiğinde de tekrarlayın. İşletim sistemi güncellemesi, yeni bir tarayıcı profili ya da eklenen bir güvenlik yazılımı çözümleyici tercihini sessizce değiştirebilir ve aylar önce doğru kurulmuş bir kapsam farkında olmadan açılabilir.

Tünelin içinde ne görünür, ne görünmez?

Şifreli bir bağlantı istendiğinde istemci proxy’ye önce bir tünel açma isteği gönderir. Bu istekte hedef ana bilgisayar ve port açıkça yazılıdır; proxy nereye bağlanacağını buradan öğrenir. Kimlik doğrulama gerekiyorsa kullanıcı adı ve parola ayrı bir başlıkta taşınır.

Tünel kurulduktan sonra istemci ile sunucu arasında şifreli el sıkışma başlar. Bu aşamada sunucu adı göstergesi hâlâ görülebilir durumdadır; ondan sonrasında akan her şey proxy için anlamsız bayt dizisidir. Depo adı, dosya içeriği, taahhüt mesajları ve erişim jetonu proxy tarafından okunamaz.

Bu ayrım iki yönlü bir sonuç doğurur. Bir yandan sağlayıcınız kodunuzu göremez; öte yandan hangi ana bilgisayarlara ne sıklıkla bağlandığınız kayıt altına alınabilir. Sağlayıcı seçimini bir güven kararı hâline getiren şey tam olarak budur.

Erişim bilgisini adres satırına gömmek yaygın ama riskli bir alışkanlıktır; kabuk geçmişi, betik dosyaları ve hata çıktıları o satırı olduğu gibi saklar. Kimlik bilgisini ayrı bir yapılandırma dosyasında ya da ortam değişkeninde tutmak, kazara paylaşılan bir günlük dosyasının çıkışınızı üçüncü kişilere açmasını önler.

Çoklu cihaz ve eşzamanlı oturum davranışı

Aynı hesabı dizüstü bilgisayardan, masaüstünden, telefondan ve bir sunucudaki koşucudan aynı anda kullanmak olağandır. Platform bu eşzamanlılığı bekler; her cihaz kendi kimlik bilgisini taşır. Tarayıcı bir oturum çerezi, git istemcisi bir jeton veya anahtar, koşucu ise ayrı bir kimlik kullanır.

Proxy devreye girdiğinde dikkat edilecek nokta, tüm cihazların aynı çıkışa zorlanmasının gerekmediğidir. Aksine, her cihazın kendi bağlamına uygun bir kapsamı olması daha sağlıklıdır: geliştirici makinesi bölgesel doğrulama için bir çıkış kullanırken, koşucu sabit ve kurum tarafından tanınan bir adresten çıkabilir.

Eşzamanlı bağlantı sayısının proxy tarafında da bir sınırı olduğunu unutmayın; paralel klonlama yapan bir koşucu tek başına birkaç bağlantı açar. Sınırların nasıl hesaplandığını eşzamanlı bağlantı limiti yazısı açıklıyor.

İstek sınırları adrese mi, jetona mı bağlıdır?

Programatik erişimde kritik ayrım şudur: kimliklenmemiş istekler genellikle isteğin geldiği adrese göre sayılır, kimliklenmiş istekler ise kullanılan jetona göre. Bu ayrım, proxy’den ne beklemeniz gerektiğini de belirler.

Jetonla kimliklenen bir betikte çıkış adresini değiştirmek sayacı sıfırlamaz; sınır jetona yazılıdır. Dolayısıyla “rotasyon açarsam daha fazla istek atarım” beklentisi bu senaryoda karşılığı olmayan bir varsayımdır. Doğru yaklaşım, isteği azaltmak, sonuçları önbelleğe almak ve sunucunun döndürdüğü bekleme yönergelerine uymaktır.

Adrese bağlı sınırın anlamlı olduğu yerler farklıdır: paylaşımlı bir ofis çıkışından çalışan çok sayıda geliştirici, hepsi kimliklenmemiş istek atıyorsa aynı sayacı tüketir. Böyle bir durumda ekibe ayrı bir çıkış vermek ya da istekleri kimliklendirmek sorunu kaynağında çözer.

Otomasyonun proxy tarafındaki genel çerçevesini otomasyon ve botlar için proxy sayfası, adres havuzunun nasıl yönetileceğini ise proxy havuzu yazısı ele alıyor. Her iki durumda da platformun kullanım koşullarına uymak temel şarttır.

Ne zaman proxy gerekir, ne zaman fazladan katmandır?

Kendi ülkenizden, kendi bağlantınızla, tek bir hesapla çalışıyorsanız araya proxy koymak size bir şey kazandırmaz; yalnızca bir arıza noktası ve biraz gecikme ekler. Bu durumda yapılandırmayı olduğu gibi bırakmak en iyi karardır.

Proxy anlamlı hâle geldiği durumlar genellikle şunlardır: erişimin belirli adreslerle sınırlandırıldığı kurumsal ağlarda sabit ve tanınan bir çıkıştan konuşmak, farklı bölgelerden dağıtılan bir dokümantasyon sitesinin nasıl göründüğünü doğrulamak, test ortamının trafiğini üretim trafiğinden ayırmak ve kısıtlı bir ağdan çıkarken tek bir denetlenebilir kapı kullanmak.

Karar verirken maliyeti de hesaba katın. Klonlama ve arşiv indirme hacimli işlerdir; ölçüm yapmadan sınırsız bir kullanım varsaymak sürprizle sonuçlanır. Deneme aşamasında nelerin sınanacağını deneme sürümü nasıl test edilir yazısı sıralıyor.

Bir başka ölçüt ekip büyüklüğüdür. Tek kişilik bir kurulumda yapılandırmayı hatırlamak kolaydır; on kişilik bir ekipte herkesin makinesinde aynı ayarın doğru durduğunu varsaymak gerçekçi değildir. Bu noktada kapsamı kişisel makinelere değil, ortak koşuculara ve paylaşılan ortamlara taşımak çok daha dayanıklı bir çözüm olur.

Farklı bir ekosistemde aynı soruların nasıl karşılık bulduğunu görmek isterseniz GitLab proxy sayfası, sürekli tümleştirme ve nesne deposu tarafına daha ayrıntılı giriyor.