OpenVPN için SOCKS5 proxy: TCP tüneli mi, uygulamaları proxylemek mi?

Yalnızca proxy üzerinden çıkışa izin veren ağlar, çalışan bir profilun aniden öldüğü yerdir. Proxy adresi o başarısızlıktaki en az ilginç değişkendir. Her şeye proxy'nin ileteceği trafiğin şekli karar verir, çünkü bu proxyler bir bayt akışı iletir ve UDP tüneli öyle değildir. Bu iki mimari bırakır ve ikisi farklı yerlerde kırılır.

Tasarımı tek bir kısıt belirler

SOCKS5 gerçekten bir UDP ilişkilendirme modu tanımlar. Yine de OpenVPN istemcisinin proxy desteği akışlar etrafında kurulmuştur: socks-proxy TCP profilleri için belgelenmiştir ve bir HTTP CONNECT proxy'sinin datagramlar için hiçbir yolu yoktur. Tek bir belge satırı, bir yapılandırma dosyasına dokunmadan önce mimariyi belirler.

Dolayısıyla soru hangi proxy'yi seçeceğiniz değil. Soru, tünelin bir akışa mı dönüştüğü, yoksa datagram olarak kalıp proxylemenin başka bir şey tarafından emilmesine mi izin verdiğidir.

Seçenek A: tüneli akışa dönüştürün

Bu, TCP dinleyicisi olan bir sunucu ve proxy'yi adlandıran bir istemci profili gerektirir. İki parça da gereklidir ve insanların unuttuğu sunucu tarafıdır:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

Son satırı http-proxy proxy.internal 8080 ile değiştirin, proxy HTTP konuştuğunda, ve isterse bir kimlik bilgisi dosyası ekleyin. Proxy, VPN portunuza CONNECT yapmaya istekli olmalı ve sunucu TCP üzerinde yanıt vermelidir; yalnızca UDP dinleyicisi bu girişimi yok sayar. 443'ü seçmek pratik bir hamledir, çünkü birçok kısıtlayıcı ağ ona ve az başka şeye izin verir.

Bedel, TCP'nin TCP üzerine yığılmasıdır. Kaybolan tek bir dış segment, o bağlantıyı paylaşan her iç akışı durdurur, bu yüzden normalde bağımsız olacak kurtarma paylaşılan hale gelir. Kurulum da daha uzun sürer ve kararsız bir dış yol yavaş değil, kararsız bir tünel olur.

Seçenek B: tüneli rahat bırakın

Tünel UDP'de kalması gerektiğinde, bir şey yapılandırdığınız yer tünel değildir. Bunun yerine uygulamalardan çıkan TCP yerel bir SOCKS dinleyicisine yönlendirilir ve uygulamalar bir proxy olduğunu asla öğrenmez. Linux'ta bu genellikle redsocks artı nat tablosunda bir NAT REDIRECT kuralıdır.

Yine yalnızca TCP. privoxy gibi yalnızca HTTP proxy'si rastgele protokolleri iletemez ve bu tasarım uygulamalara datagram desteği de eklemez.

Her uygulamaya proxy'yi doğrudan söylemek, yazılımın desteklediği yerlerde genellikle daha iyidir. Denetlemesi daha kolaydır ve gerçekten görebildiğiniz bir yerde başarısız olur.

Her seçenek nerede başarısız olur

Seçenek A, sunucuda TCP dinleyicisi yoksa, proxy CONNECT hedefini reddederse veya dış akış tünelin ihtiyacının altına kısılırsa başarısız olur. İlk ikisi proxy günlüğünde bir kayıt bırakır; üçüncüsü kurulan ve sonra yanlış hissettiren bir bağlantı bırakır. Profili düzenlemeden önce o günlüğü okuyun, çünkü izin sorununu kapasite sorunundan ayırır. Tamamlanan CONNECT soruşturmayı tünelin içine taşır.

Seçenek B, datagram gerektiren her şey için, proxy'nin anlamadığı protokoller için ve yönlendirme kuralının var olduğu ama yönlendirmenin trafiği yanından geçirdiği konaklarda sessizce başarısız olur.

Hiçbir seçenek aygıt gereksinimini değiştirmez. Paketler çekirdek onları yönlendirmeden önce hâlâ bir TUN veya TAP düğümüne ihtiyaç duyar, bu yüzden süreç hâlâ /dev/net/tun üzerinde izne ihtiyaç duyar. Bir sarmalayıcı o düğüm açıldıktan sonra ne olduğunu değiştirir, ona ihtiyacınız olup olmadığını değil.

Hangi yolu kurduğunuzu kanıtlayın

Sepet simgesine değil soketlere bakın. VPN süreci proxy adresine kurulmuş bir bağlantı tutmalı ve proxy istenen hedefi günlüğe yazmış olmalıdır:

ss -tnp | grep openvpn

Sonra yalnızca tünelin hizmet edebileceği bir hedefe ve yalnızca tünelin çözümleyicisinin yanıtlayabileceği bir ada gidin. Ölü bir tünelle tamamlanan proxy bağlantısı genellikle uzak ucun profilinizde adlandırılan taşımayı hiç sunmadığı anlamına gelir.

Taşımayı ve kabul eden proxy'yi kalıcı bir yere not edin. Aynı profil başka bir ağda başarısız olduğunda, bu not proxy'yi saniyeler içinde dışlar veya doğrular.