Redsocks loopback'te dinliyor ama VPN trafiği asla ulaşmıyor

Bir tünel açılır, istemci ağ geçidine ping atabilir, ancak proxy yolundan geçen her web isteği ölür. redsocks süreci çalışıyor ve portu dinliyor, bu yüzden hizmet ağ geçidinin kendisinden sağlıklı görünüyor. Başarısız olan teslimat adımıdır: tünelden yönlendirilen bir paket başlattığınız sokete inmez. Bağlama adresi ile yönlendirme hedefi uyuşmalıdır ve genellikle yalnızca biri kontrol edilir.

Yönlendirilen bir paket gerçekte nereye iner

Ağ geçidindeki saydam proxy, gelen bir bağlantının hedefini yerel bir porta yeniden yazmak için PREROUTING'deki nat tablosunda REDIRECT kullanır. Yeniden yazılan hedef, paketin geldiği arayüzden görülen yerel adrestir, başka bir yerde başlatılan bir sürecin loopback adresi değildir. Yalnızca 127.0.0.1'e bağlı bir dinleyici, zaten ana bilgisayarda yerel olan bağlantıları kabul eder ve tünel trafiği başarısız olurken çalışmaya devam eden durum tam da budur. İstemcinin kendi loopback'i üçüncü bir adrestir ve asla ağ geçidi kuralının hedefi değildir.

Bu nedenle üst düzey kimlik bilgilerine dokunmadan önce iki gerçeği belirleyin: kuralın hangi yerel adrese yeniden yazdığını ve proxy soketinin hangi adrese bağlı olduğunu.

Dinleyiciyi ve yönlendirme kuralını birlikte okuyun

Soket tablosunu ve nat kurallarını tek geçişte yazdırın, çünkü kimsenin sahip olmadığı bir porta işaret eden kural, yanlış adrese işaret eden kuralla aynı görünür. sudo ss -ltnp | grep redsocks bağlama adresini ve sahip süreci gösterir. sudo iptables -t nat -S PREROUTING REDIRECT hedefini gösterir ve sudo iptables -t nat -L PREROUTING -v -n herhangi bir şeyin onunla eşleşip eşleşmediğini gösterir.

REDSOCKS adlı bir kullanıcı zincirine atlama, o zincir var olmadıkça ve amaçlanan istisnaları ve REDIRECT eylemini taşımadıkça hiçbir şey elde etmez. Adın işi yaptığını varsaymak yerine atladığı zinciri sudo iptables -t nat -S REDSOCKS ile okuyun.

Ardından iki değeri karşılaştırın. Kural 12345 portundaki bir ağ geçidi adresine yönlendiriyorsa ve dinleyici 127.0.0.1:12345 bildiriyorsa, uyuşmazlık hatayı başka bir teşhis olmadan açıklar.

Dar bağlayın, sonra ona neyin ulaşabileceğini sınırlayın

Üst düzey örnek yapılandırma, dinleyiciyi iyi bir nedenle loopback'e yerleştirir: saydam bir proxy, ona ulaşabilen herkes adına bağlantı kabul eder. Bağlamayı 0.0.0.0 olarak değiştirmek teslimatı düzeltir ve aynı anda portu her arayüzde açar; bu bir güvenlik değişikliğidir, nötr bir onarım değildir. Yönlendirmenin hedeflediği belirli yerel adrese bağlanmayı tercih edin ve güvenilmeyen arayüzlerde portu kapalı tutun. Daha geniş bir bağlama kaçınılmazsa, yalnızca tünelin kaynak aralığına ve ağ geçidinin kendi yerel trafiğine izin veren bir ana bilgisayar güvenlik duvarı kuralı ekleyin.

Genel arayüzde portu açmak, yönlendirilmiş VPN trafiği için asla gerekli değildir, çünkü bağlantı yeniden yazmadan sonra yerel olarak sonlanır. Yerel bir yönlendirmenin çalışması için proxy'yi internete maruz bırakmayın.

Bir istemciden yeni bağlantıyla kanıtlayın

Ağ geçidindeki bir kabuktan değil, gerçek bir VPN istemcisinden yeni bir TCP bağlantısıyla test edin. İstemcideki curl -sS -o /dev/null -w '%{http_code}\n' http://example.com yönlendirilen yolu baştan sona çalıştırır.

Ardından, güvenilmeyen bir ağdan dinleyiciye doğrudan bağlantının hâlâ reddedildiğini ve proxy'nin kendi üst bağlantısının aynı kuralla yeniden yakalanmadığını doğrulayın. Yinelemeli yakalama, kendine bağlanan ve isteği asla tamamlamayan bir proxy olarak görünür. Proxy'nin hedefini istisna kümesine ekleyin veya giden paketlerini işaretleyin ki zincir onları atlasın.

Son olarak, bu yolun neleri kapsamadığını unutmayın. Normal redsocks TCP yönlendirmesi UDP, QUIC veya DNS'i SOCKS trafiğine dönüştürmez ve özel hedefler genellikle açık istisnalar gerektirir. Başarılı bir yerel test yalnızca asla sorun olmayan loopback yolunu kanıtlar.