Politika yönlendirmesi SOCKS'a karşı: trafiği gerçekte hangi katman proxy'liyor

1080 numaralı portta SOCKS dinleyicisi çalışan bir ana bilgisayara VPN istemcisinin trafiğini gönderen bir politika rotası eklediniz. Paketler ulaşır, dinleyici hiçbir şey kaydetmez ve bağlantı askıda kalır. Rotada yanlış bir şey yok: sonraki atlama bir paketin nereye gideceğini seçer, SOCKS ise istemcinin başlatması gereken bir konuşmadır. İnsanların trafiği bir proxy üzerinden göndermekten genellikle kastettikleri üç mimariyi karşılaştırın, kurulumunuzda hangi parçanın eksik olduğu netleşecektir.

Yönlendirme, DNAT ve SOCKS farklı şeyleri değiştirir

Politika rotası katman 3 kararını yeniden yazar. Bir istemcinin trafiğini seçilen sonraki atlamaya göndermek için iki satır yeterlidir:

ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101

Ardından çekirdek paketi 10.50.0.2'ye verir, özgün hedef hâlâ IP başlığındadır. 10.50.0.2 bir yönlendiriciyse paketi iletir. 1080'de SOCKS arka plan programı olan bir ana bilgisayarsa, paket onu kabul edebilecek hiçbir şeye adreslenmemiştir ve 1080 numaralı porta DNAT da yardımcı olmaz, çünkü çevrilmiş paket hâlâ SOCKS selamlaması yerine özgün uygulama yükünü taşır.

SOCKS5 sürüm baytı, yöntem listesi, kimlik doğrulama alışverişi ve hedefi adlandıran bir istekle başlar. Bunlar uygulama verisidir. Hiçbir yönlendirme kaydı ve hiçbir netfilter hedefi bunları üretmez ve tek satırdaki karşılaştırma şudur: yönlendirme bir yol seçer, SOCKS bir sunucudan ikinci bağlantı kurmasını ister.

Birinci durum: uygulama SOCKS'i kendisi konuşabilir

Programın bir proxy ayarı varsa bu en kısa yoldur ve çekirdekte değişiklik gerektirmez. Onu dinleyiciye yönlendirin, sunucu isterse kimlik bilgilerini verin ve adların yerel olarak mı çözüleceğine yoksa proxy'ye mi aktarılacağına karar verin. curl'de bunlar farklı bayraklardır ve hedef yalnızca proxy tarafından çözüldüğünde fark önemlidir:

curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.com

Proxy ortam değişkenlerini yok sayan veya ham soketler açan uygulamalara bu şekilde yardımcı olunamaz. Tarayıcılar ve çoğu HTTP aracı sorunsuzdur; bir oyun istemcisi, posta arka plan programı veya herhangi bir satıcı ikili dosyası genellikle değildir. Sınır her uygulama ve her protokol içindir, bu yüzden bu seçenek test için mükemmel, tüm VPN için yanıt olarak zayıftır.

İkinci durum: IP akışlarını proxy oturumlarına dönüştüren bir adaptör

SOCKS konuşamayan programlar için dönüşüm, IP trafiğini sonlandıran ve onlar adına proxy oturumları açan bir şeyde gerçekleşmelidir. Bu bileşen bir tünel arayüzüne sahiptir, politika yönlendirmesinin seçtiği akışları kabul eder, her biri için SOCKS el sıkışmasını yapar ve yanıtları yeniden kurar. Rota trafiği ona yönlendirir; oturumu oluşturan adaptördür.

Tüm bir alt ağı ona emanet etmeden önce belgelerini okuyun. Birçok adaptör TCP'yi iyi taşır ve UDP'yi yalnızca SOCKS5 UDP birliği üzerinden işler ve hiçbiri ICMP'yi proxy trafiğine çevirmez, bu yüzden başarılı bir ping proxy yoluna dair hiçbir şey söylemez. DNS diğer tuzaktır: adaptör adları yerel olarak çözerse, yalnızca dahili kayıtlar yanlış yanıta veya hiçbir şeye çözülür.

Döngü önleme, ısıran operasyonel ayrıntıdır. Adaptörün SOCKS sunucusuna kendi bağlantıları tekrar adaptöre yönlendirilmemelidir, bu yüzden trafiğinin kuralda bir istisnaya veya özel bir kaynak adresine ihtiyacı vardır. Bunu yanlış yaparsanız proxy oturumu kendini proxy'lemeye çalışır.

Üçüncü durum: ana bilgisayar aslında yönlendirilmiş bir ağ geçididir

Bazen çalışan kurulumda hiç SOCKS yoktur. Uzak ana bilgisayar paketleri iletir veya onlara NAT uygular ve kaynak tabanlı kural onu yalnızca çıkış olarak seçer. Bu tasarım meşrudur ve kopyalanmış bir yapılandırmanın bir ağda çalışıp diğerinde neden başarısız olduğunu açıklar: kural aynıdır, eksik parça karşı taraftaki iletim hizmetidir.

Üç durum hızla ayrılır. Gerçekte neyin dinlediğini kontrol edin, sonra ana bilgisayara ulaşan ilk baytlara bakın:

ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'

Gerçek bir SOCKS istemcisinin ilk yük baytı 0x05'tir, selamlamadaki sürüm. Yakalama bunun yerine özgün uygulama verisini gösteriyorsa hiçbir SOCKS arka plan programı yanıt vermez, çünkü görüşmeler hiç başlamamıştır. 1080'de hiçbir şey dinlemiyorsa ana bilgisayar bir ağ geçididir ve soru onun ilettiğine ve bir dönüş yolu olup olmadığına dönüşür.

Katmanı dört soruyla seçin

Programın proxy ayarı var mı? Kullanın ve orada durun. Trafikte hayatta kalması gereken UDP veya ICMP var mı? ICMP'yi yalnızca yönlendirilmiş veya NAT ağ geçidi taşır ve UDP her iki uçta desteklenen bir SOCKS5 birliği gerektirir. Makinedeki her süreç, yapılandıramadıklarınız dahil kapsanmalı mı? O zaman arayüze sahip olan ve akışları sonlandıran bir adaptöre ihtiyacınız var. Onun yönlendirmesini, DNS'ini ve döngü önleme istisnalarını da üstlenebilir misiniz? Değilse, düz ağ geçidinin işletmesi daha ucuza gelecektir.

Bir ayrımı net tutmakta yarar var. Bir VPN istemcisinin kendi socks-proxy seçeneği dış tünel bağlantısının sunucusuna nasıl ulaştığını açıklar ve iç istemci akışlarının dönüştürülmesi hakkında hiçbir şey söylemez. İkisi aynı bilette sürekli karıştırılır. Bir rotaya dokunmadan önce hangi ilişkiye ihtiyacınız olduğuna karar verin.