Şeffaf TCP-SOCKS yönlendirmede özgün hedefler
Şeffaf TCP-SOCKS yönlendirmesinin proxy ile pazarlık etmeden önce özgün hedefi geri kazanan bir çeviriciye neden ihtiyaç duyduğunu açıklar.
Bir güvenlik duvarı TCP bağlantısının nereye indiğini değiştirebilir. Ancak yalnızca bu değişiklikle kaynak uygulamaya SOCKS konuşmayı öğretemez.
Sıradan bir SOCKS sunucusu, istenen hedefi tanımlayan bir pazarlık bekler. Proxy'yi bilmeyen bir uygulama bunun yerine kendi protokol baytlarını hemen gönderir. Bu baytları doğrudan bir SOCKS dinleyicisine yönlendirin; iki taraf ilk mesaj konusunda anlaşamaz.
Eksik bileşen bir çeviricidir
Şeffaf TCP-proxy bileşeni bu arayüzlerin arasında durur. Uygulamanın başlangıçta istediği hedefi bulur, uygun SOCKS veya HTTP CONNECT oturumunu kurar ve ardından uygulama verilerini oluşan akış üzerinden aktarır.
Linux iptables yolunda redsocks kaynağı korunan hedefi SO_ORIGINAL_DST aracılığıyla alır. Diğer işletim sistemleri ve yönlendirme yöntemleri farklı mekanizmalar kullanır. Bu, yönlendiricinin ve ağ kurulumunun bir özelliğidir; sıradan bir SOCKS istemcisinin işlevi değildir.
Özgün hedef bilgisi ayrıca bir yönlendirme kuralını proxy sunucusundan ilgisiz bir ağ geçidine taşımanın neden her zaman eşdeğer olmadığını da açıklar. Alıcı süreç, kendi yakalama kipinin gerektirdiği üst verilere ihtiyaç duyar. Başka yerde yeniden yazılan bir adres bu bilgiyi artık beklenen biçimde sağlamayabilir.
Çeviricinin kapsamını açık tutun. Çalışan yönlendirilmiş bir TCP bağlantısı, gelişigüzel UDP, ICMP veya her çözümleyici yolu için destek kanıtlamaz. Üst proxy protokolü ve çeviricinin uygulanışı desteklenen işlemleri hâlâ belirler.
Bir kurulum bağlantıdan hemen sonra başarısız olursa, erişim kurallarını genişletmeden önce protokol sınırını denetleyin. Kusursuz biçimde erişilebilen bir SOCKS dinleyicisi bile hiç SOCKS isteği olmamış baytları reddedebilir.