SOCKS5 üzerinden OpenVPN: sürüm, taşıma ve DNS eşleştirme

SOCKS zinciri, proxy sürümü, taşıma veya DNS yolu uyuşmadığında başarısız olur. SOCKS5'i eşleştirin, TCP taşıyın ve zinciri tek bir ad alanı içinde tutun.

Bu iş istasyonundan dışarı çıkan bir yol SOCKS proxy'sidir ve arkasındaki OpenVPN hiçbir yararlı ayrıntı olmadan bağlantı zaman aşımı bildirir. Aynı makinedeki tarayıcı o proxy üzerinden çalışır, kimlik bilgileri doğrudur ve port yanıt verir. Üç şey ilk kontrol edilecek kadar sık farklılaşır: proxy'nin konuştuğu SOCKS sürümü, istemcinin seçtiği taşıma ve ad çözümlemesinin gerçekleştiği yer. Güvenlik duvarını suçlamadan önce her birini doğrulayın.

Güvenlik duvarından önce SOCKS sürümünü eşleştirin

Topluluk OpenVPN, socks-proxy için SOCKS5 konuşur. Yalnızca SOCKS4 sunan bir proxy'ye yönlendirin; TCP bağlantısı açılır ve sonra takılır, çünkü istemci karşı tarafın hiç ayrıştırmadığı bir selamlamaya yanıt bekler. Dışarıdan bu takılma tam olarak filtrelenmiş bir port gibi görünür, bu yüzden sürüm sorusu herhangi bir güvenlik duvarı kuralından önce gelir. SOCKS bilen tek bir getirme bunu tek komutla çözer.

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example

Tamamlanan istek aynı anda iki şeyi kanıtlar: proxy SOCKS isteğini kabul etti ve adı çözdü. URL şeması gerekmez, çünkü curl çıplak ana bilgisayarı HTTP olarak işler ve bu test için yeterlidir.

O getirme, istemci günlüğünün gizlediği hatayı da dışlar. Proxy tarayıcıya izin verip VPN hedefini yine de reddedebilir; o zaman ret CONNECT aşamasında, herhangi bir VPN kimlik doğrulamasından önce olur. OpenVPN yalnızca zaman aşımı bildirir, bu yüzden proxy'nin kendi yanıtı ihtiyacınız olan kanıttır.

Taşıma iki tarafta da TCP olmalı

SOCKS5 burada bir TCP akışı taşır, bu yüzden tünelin kendisi proto tcp-client gerektirir. Hâlâ UDP'ye ayarlı bir profil bu yoldan çalışmaz, çünkü istemci protokolün UDP ilişkilendirme kipini kullanmaz. Profili ters çevirmek biçimsel değil gerçek bir değişikliktir: uzak taraf aynı portta TCP dinlemelidir. Sonra yük TCP içinde TCP olur; kaybolan segment iki kez yeniden gönderilir ve tempo bozulur, bunu etkileşimli oturumlar büyük aktarımlardan çok daha fazla hisseder.

proto tcp-client
remote gw.lab.example 8443
socks-proxy 127.0.0.1 9050

Bu yönerge proxy ana bilgisayarını, isteğe bağlı bir portu ve isteğe bağlı bir kimlik bilgisi dosyasını alır. Bunları profilin kendisine koyun ki başka yerdeki bir kopya aynı davransın.

Tüm zinciri tek bir konteynere kapatın

Zinciri ana makinede yapmak, onun varsayılan rotasını devralmak ve çözümleyiciyi sonradan kimsenin açıklayamayacağı bir durumda bırakmak demektir. Bunun yerine bir ad alanı ya da konteyner onu sınırlar, böylece ana makine kendi yolunu korurken SOCKS sıçraması ve tünel birlikte yaşar. İçeride tünel aygıtı, onu yapılandırma hakları ve erişilebilir bir proxy olmadan hiçbir şey kalkmaz. Bir Compose hizmeti bunu cap_add: NET_ADMIN ve bind ile bağlanmış /dev/net/tun ile elde eder.

cap_add:
  - NET_ADMIN
devices:
  - /dev/net/tun:/dev/net/tun

Bu çift, konteyneri ayrıcalıklı çalıştırmaktan daha dar ve gereken aygıt erişiminin tamamı bu. Bir Tor istemcisi veya ayrı bir proxy konteyneri dinleyiciyi sağlayabilir. Her iki durumda da onu loopback'e bağlayın ve proxy'yi ağa açmak yerine ad alanından ana makine üzerinden ona ulaşın.

Yalıtımın koptuğu yer ad çözümlemesidir

Paketleri taşıyıp yine de ana makinenin çözümleyicisine soran bir tünel hiçbir şeyi yalıtmamıştır. İki şey yalıtımı gerçek kılar: ad alanının kendi çözümleyicisi vardır ve sorguları proxy ya da tünel üzerinden gider, asla fiziksel arabirimden. Test için iki ad kullanın: yalnızca tünelin arkasında var olan biri ve aynı yolu izlemesi gereken bir genel ad.

docker compose exec vpn cat /etc/resolv.conf
docker compose exec vpn getent hosts internal.lab.example

Uzak addaki çözümleme olup genel addaki olmuyorsa zincir bozuk değil seçicidir ve fark her sorgunun hangi yolu izlediğini söyler. İkisi de ana makineden çözümlenip konteyner içinde hiçbiri çözümlenmiyorsa konteyner hâlâ ana makinenin çözümleyicisini ödünç alıyordur. Bulduğunuz çözümleyici dosyasını kaydedin, çünkü değiştirilmesi gereken ayar odur.

Her sıçramayı sırayla kanıtlayın

Liste kısa. Bir SOCKS5 isteği yanıt alır, tünel proxy üzerinden dinleyicisine ulaşır ve ad alanından çıkan paketler uzak tarafın beklediği adresi taşır. Daha fazla yapılandırma yığmak yerine tek tek doğrulayın. İstemci bağlandı deyip hiçbir şey kımıldamıyorsa kopukluk neredeyse her zaman ikinci ya da üçüncü gerçekte olur.

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example
docker compose exec vpn ip route get 203.0.113.10
docker compose exec vpn getent hosts internal.lab.example

İşe yarayan bileşimi yazın: SOCKS sürümü, taşıma, çözümleyici ve ad alanı ayarları. Bu zinciri ikinci kez hafızadan çözmek nottan daha pahalıdır. O dört gerçeği sohbette değil kayıtta tutun.

Bağlandığını bildirip hiçbir şey geçirmeyen bir zincir genellikle henüz kanıtlamadığınız sıçramada başarısız olmuştur. Başka bir katman eklemeden önce o sıçramayı test edin.

İlgili makaleler