Wireproxy: HTTP/SOCKS5 proxy olarak sunulan WireGuard istemcisi

 (github.com/pufferffish)
2 puan yazan GN⁺ 2024-04-03 | 1 yorum | WhatsApp'ta paylaş
  • Wireproxy, bir WireGuard peer’ına bağlandıktan sonra yerel makinede SOCKS5/HTTP proxy veya tünel olarak açığa çıkan, tamamen kullanıcı alanında çalışan bir WireGuard istemcisidir
  • Yeni bir ağ arayüzü kurmadan yalnızca belirli site trafiğini WireGuard peer’ına göndermek isteyenleri veya WireGuard yapılandırma değişiklikleri için root yetkisi kullanmak istemeyenleri hedefler
  • Özellikleri TCP statik yönlendirme, SOCKS5/HTTP proxy ve TLS SNI tabanlı transparent proxy içerir; HTTP proxy şu anda yalnızca CONNECT destekler
  • Yapılandırma, wg-quick’in [Interface] ve [Peer] semantiklerini izler; mevcut WireGuard yapılandırma dosyası WGConfig ile içe aktarılabilir veya birden fazla peer AllowedIPs ile yönlendirilebilir
  • Operasyonel kullanım için --info/-i tabanlı bir health endpoint sunar; /metrics ve /readyz ile WireGuard durumunu ve CheckAlive tabanlı hazır olma durumunu kontrol edebilirsiniz

Wireproxy ne yapar

  • wireproxy, WireGuard peer’ına bağlanan ve yerel makinede SOCKS5/HTTP proxy veya tünel açığa çıkaran bir kullanıcı alanı uygulamasıdır
  • Yalnızca belirli sitelere WireGuard peer’ı üzerinden erişmek, ancak yeni bir ağ arayüzü oluşturmak istemediğinizde kullanılabilir
  • Ağ arayüzünden tamamen bağımsız çalışır ve yapılandırma için root yetkisi gerektirmez
  • Amnezia VPN’e benzer bir kullanım gerektiren kullanıcılar wireproxy-awg fork’unu kullanabilir

Desteklenen ve henüz olmayan özellikler

  • Desteklenen özellikler
    • İstemci ve sunucu için TCP statik yönlendirme
    • SOCKS5/HTTP proxy
      • HTTP şu anda yalnızca CONNECT destekler
    • Server Name Indication kullanan transparent TLS proxy
  • TODO olarak kalan özellikler
    • SOCKS5 için UDP desteği
    • UDP statik yönlendirme

Çalıştırma ve kurulum

  • Temel çalıştırma biçimi ./wireproxy [-c path to config] şeklindedir
  • Başlıca seçenekler
    • -c, --config: yapılandırma dosyası yolunu belirtir
      • Varsayılan yollar /etc/wireproxy/wireproxy.conf, $HOME/.config/wireproxy.conf
    • -s, --silent: silent mode
    • -d, --daemon: arka planda çalıştırma
    • -i, --info: health status’u açığa çıkarmak için adres ve port belirtir
    • -v, --version: sürümü yazdırır
    • -n, --configtest: yalnızca yapılandırma dosyasının geçerliliğini kontrol eder
  • Derleme, depoyu klonladıktan sonra make ile yapılır
  • Kurulum örneği olarak go install github.com/windtf/wireproxy/cmd/wireproxy@v1.1.2 veya @latest kullanılır

Yapılandırma modeli

  • [Interface] ve [Peer] ayarları, wg-quick yapılandırmasıyla aynı semantiği izler
  • Address, IPv4 için /32, IPv6 için /128 alt ağını kullanmalıdır
  • PrivateKey ortam değişkeni referanslarını da kullanabilir
  • Mevcut bir WireGuard yapılandırmanız varsa WGConfig = <path to the wireguard config> ile içe aktarabilirsiniz

Tünel ve proxy ayarları

  • TCPClientTunnel
    • Yerel makinede alınan TCP trafiğini WireGuard üzerinden belirtilen hedefe iletir
    • Örnek akış <LAN uygulaması> → localhost:25565 → WireGuard → play.cubecraft.net:25565 şeklindedir
  • TCPServerTunnel
    • WireGuard ağında alınan TCP trafiğini yerel ağdaki belirtilen hedefe iletir
    • Örnek akış <WireGuard ağ uygulaması> → WireGuard → 172.16.31.2:3422 → localhost:25545 şeklindedir
  • STDIOTunnel
    • wireproxy sürecinin standart giriş ve çıkışını WireGuard üzerinden TCP hedefine bağlar
    • openssh’in ProxyCommand parametresi olarak kullanmak için uygundur
  • Socks5
    • Yerel LAN’da bir SOCKS5 proxy oluşturur ve tüm trafiği WireGuard’a yönlendirir
    • Kullanıcı adı ve parola belirtildiğinde proxy kimlik doğrulamasını etkinleştirir
  • http
    • Yerel LAN’da bir HTTP proxy oluşturur ve tüm trafiği WireGuard’a yönlendirir
    • Kullanıcı adı ve parola belirtildiğinde kimlik doğrulamayı etkinleştirir
    • CertFile ve KeyFile belirtilirse HTTPS’yi etkinleştirir
  • SNI
    • Yerel LAN’da transparent TLS proxy oluşturur ve trafiği WireGuard üzerinden göndermek için SNI’ı yönlendirme hedefi olarak kullanır

Birden fazla peer ve yönlendirme

  • Birden fazla WireGuard peer’ı kullanılabilir
  • Birden fazla peer kullanırken wireproxy’nin hangi peer’a ileteceğini bilmesi için AllowedIPs belirtilmelidir
  • Yapılandırma örneği, farklı AllowedIPs değerlerine sahip birden fazla [Peer] ile birden fazla TCPServerTunnel kullanımını birlikte gösterir
  • UDPProxyTunnel örneği de dahildir
    • BindAddress ile yerel bind adresi belirtilir
    • Target ile hedef adres belirtilir
    • InactivityTimeout 0 ise timeout olmaz
  • [Resolve] DNS çözümleme stratejisini ayarlar
    • ipv4: A kayıtlarına öncelik verir
    • ipv6: AAAA kayıtlarına öncelik verir
    • auto: varsayılandır; WireGuard arayüzünde yalnızca IPv4 adresi varsa ipv4 ile, aksi halde ipv6 ile aynıdır
  • Endpoint’i olmayan [Peer] yapılandırmasıyla peer’ın wireproxy’ye bağlanmasına izin verilebilir

Health endpoint

  • --info/-i, örneğin localhost:9080 gibi bir adres ve port alarak health status metric sağlayan bir HTTP sunucusunu açığa çıkarır
  • Şu anda iki endpoint uygulanmıştır
    • /metrics: WireGuard daemon bilgilerini açığa çıkarır ve wg show ile aynı bilgileri sağlar
    • /readyz: CheckAlive içinde belirtilen IP’den en son pong alınan zamanı JSON olarak döndürür
  • CheckAlive ayarlandığında, belirtilen adrese her CheckAliveInterval saniyede bir WireGuard üzerinden ping gönderir
    • Varsayılan CheckAliveInterval 5 saniyedir
    • Son CheckAliveInterval saniyesine 2 saniyelik gecikme payı eklenen süre içinde pong alınamazsa 503 döndürür
    • Koşul sağlanırsa 200 döndürür
  • CheckAlive ayarlanmamışsa /readyz boş bir JSON nesnesi ve 200 döndürür
  • ICMP ping paketinin yönlendirileceği peer, her peer’ın AllowedIPs ayarına göre değişir

İlgili okumalar

1 yorum

 
GN⁺ 2024-04-03
Hacker News yorumları

  • Küçük ama harika bir araç. Firefox’un multi-account containers özelliğiyle yalnızca belirli sekmeleri seçip, WireGuard’ı destekleyen ama uygulama katmanı proxy’si ya da SSH’i olmayan ev yönlendiricime proxy’lemek için kullanıyorum

    • multi-account containers’ın konteyner başına proxy ayarlarını desteklediğini ilk kez öğrendim
      Bunu ayarlamak için https://addons.mozilla.org/en-GB/firefox/addon/container-pro... gibi ayrı bir eklenti gerektiğini sanıyordum; öyle değilmiş ve artık böyle bir yanılgı da downvote sebebi sayılıyor galiba
    • Böyle bir yapılandırmanın nasıl ayarlanacağını anlatan iyi bir kaynak varsa merak ederim

  • WireGuard ile yapmaya çalıştığım iş için https://github.com/dariost/soks daha uygundu. Neredeyse aynı işi yapıyor ama mevcut WireGuard arayüzünü yeniden kullanıyor
    Kullanım şekli bu yazıda ayrıntılı anlatılmış: https://www.nicoco.fr/blog/2023/09/10/wireguard/

    • Bu epey farklı. wireproxy kullanıcı alanında TCP ve WireGuard uygulamasını içeriyor gibi görünüyor; soks ise daha çok yalnızca TCP işleyebilen bir IP yönlendiricisine benziyor
      Kontrol mekanizması olarak yönlendirme tablosunu kullanmak yerine, SOCKS5 proxy kullanıp kullanmamaya karar verme biçimi gibi görünüyor
    • Neden onun daha uygun geldiğini merak ediyorum
      Geçmişte Raspberry Pi üzerinde Docker konteyneriyle benzerini yapmıştım; ancak herhangi bir işletim sisteminde çalışabilmesi ve ana makinenin yönlendirme tablosunu yanlışlıkla bozmayacağını garanti etmesi nedeniyle kullanıcı alanı çözümü çok daha iyi bir seçenek gibi görünüyor

  • onetun da var: https://github.com/aramperes/onetun

  • Tamamen kullanıcı alanı sunucu uygulaması da var mı merak ediyorum. tun/tap aygıtı olmadan yapmak için kullanıcı alanı IP yığını gibi bir şey gerekir sanırım ama emin değilim

  • Başka bir IP gerektiğinde kullandığım SSH tünellerinin yerini almak için iyi olur
    İlgili bir araç olarak pproxy de var; özelliklerinden biri olarak farklı tünel protokollerini “dönüştürebiliyor” ve yönlendirme özelliği de var. SSH SOCKS5’i HTTP proxy’ye çevirmek için kullanmıştım: https://github.com/moreati/pproxy

  • “Böyle bir şey Go ile oldukça kolay yapılabilir,” diye düşünmüştüm; nitekim Go ile yazılmıştı

  • Birçok çok protokollü proxy istemcisi bu özelliği destekliyor. Başlıca açık kaynak örnekler arasında sing-box, clash-meta ve diğer clash tabanlı istemciler, xray var
    Kapalı kaynak istemciler arasında Surge Mac/iOS bulunuyor

    • Doğru. Bu çok protokollü proxy’ler muhtemelen Çin güvenlik duvarını aşmak için geliştirilmişti; ilginç, küçük bir ekosistem
      Pek bilinmeyen çok sayıda trafik yönlendirme olanağı var ve Android uygulamaları da bulunuyor. Eskiden hotspot desteklemeyen bir SIM ve root edilmemiş Android ile hotspot açmak için denemiştim
      Ancak internette oradan buradan alınmış çok kod içeriyorlar ve geliştirici topluluğu da çeşitli nedenlerle epey sıra dışı; bu yüzden ne kadar güvenilir olduklarını hep merak ediyorum
    • Kapalı kaynak tarafında Cloudflare WARP da proxy modunda çalışabiliyor. WARP yapılandırmasını normal WireGuard yapılandırmasına dönüştürürseniz ücretsiz hesap da bu şekilde kullanılabiliyor
    • Çin’de kararlı çalışan neredeyse tek şey clash + v2ray gibi görünüyor. Büyük VPN sağlayıcılarının çoğu Çin’de çalıştığını söylüyor ama pratikte çalışmıyor
      Çalışma şeklini derinlemesine incelemedim, ancak hangi alan adlarının VPN üzerinden proxy’leneceğine kural gruplarıyla karar verme fikrini seviyorum

  • Performansı merak ediyorum. Hatırladığım kadarıyla “vanilla” SOCKS kurulumu çok kolay; yani SSH’i uygun seçeneklerle çalıştırıp uygulamaya kullanmasını söylemek yeterli, ama epey yavaştı
    Bu araç normal SOCKS/SSH sunucusunun olmadığı durumlar için gibi görünüyor; ama o tarafta da bir avantajı var mı merak ediyorum

    • “Vanilla” SOCKS ile ne kastedildiğini merak ediyorum. Hangi başka SOCKS uygulamasıyla karşılaştırıldığını bilmiyorum
      Benim deneyimimde SSH üzerindeki SOCKS’in performansı hep oldukça iyiydi ve OpenSSH’in TUN modu gibi TCP’nin üzerine TCP bindiren bir yöntem değildi
    • İkisini karşılaştırmak güzel olurdu. Şu anda WireGuard’a bağlandıktan sonra SSH ile SOCKS proxy oluşturuyorum ve şaşırtıcı derecede iyi çalışıyor
      Yine de bu çözüme çok ilgi duyuyorum

  • Thunderbird’ün tüm e-posta bağlantılarını Tailscale exit node üzerinden proxy’leyecek, ama tüm trafiği exit node’a göndermeyecek bir araç olsa iyi olur diye tam düşünüyordum

    • tailscale CLI’ını SOCKS proxy olarak kullanabilirsiniz: https://tailscale.com/kb/1113/aws-lambda
      Bunu bir konteyner imajına koyup tailscale’in dinlediği SOCKS portunu dışarı açarsanız doğrudan proxy olur
    • exit node’un çalıştığı makineye 3proxy veya squid proxy kurabilirsiniz. Tailnet’teki tüm makineler onu görebilir

  • Mullvad VPN’e özel olarak böyle bir şeye ihtiyacınız varsa https://github.com/imiric/mullvad-proxy kullanıp memnun kalmıştım
    Benim projem değil; yalnızca güncellemeler için fork’ladım. Güzel yanı, Mullvad CLI aracını gömülü olarak getirmesi sayesinde sunucu değiştirmenin çok kolay olması ve her şeyin ana makineden yalıtılması. Ayrıca “sadece” nginx ve birkaç betikten oluştuğu için SOCKS5 desteği de iyi olur gibi