Odpowiedzi:
Dlaczego preferencje systemowe -> sieć -> (wybierz sieć po lewej stronie okna i wybierz Zaawansowane w prawym dolnym rogu) -> proxy (karta u góry) nie działają dla Ciebie?
Jeśli możesz ustawić sobie serwer SSH, darmowy sshuttle może tunelować cały ruch TCP przez połączenie, wykonując za ciebie zaporę ogniową.
Aby przekazać cały ruch TCP i żądania DNS do zdalnego serwera SSH, polecenie jest dość proste:
sshuttle --dns -vr ssh_server 0/0
Oprócz TCP i DNS sshuttle nie przekazuje innych żądań, takich jak UDP, ICMP, ping itp.
Więcej informacji i przykładów można znaleźć w artykule Korzystanie z Sshuttle w codziennej pracy .
Chociaż ustawienie ogólnosystemowych ustawień proxy jest dobrym początkiem, możesz również rozważyć użycie iptables, aby upewnić się, że cały ruch przechodzi przez proxy. Niektóre aplikacje nie używają ustawień konfiguracji całego systemu (wśród nich Firefox), dlatego konieczne jest dostosowanie reguł, aby nie zezwalać na bezpośrednie połączenia i tylko kierować ruchem przez serwer proxy.
EDYCJA: Chociaż osobiście używam iptables
reguł do zarządzania potencjalnym „wyciekiem” z mojej sieci VPN, tak naprawdę pierwotnie pomyliłem się, sądząc, że iptables może bezpośrednio współpracować z proxy skarpet. Będziesz potrzebował czegoś takiego jak tun2socks , aby stworzyć wirtualny interfejs tunelu (np. Użycie VPN).
Następnie możesz skonfigurować skrypt iptables podobny do następującego:
#!/bin/bash
if [[ $EUID -ne 0 ]]; then
echo "This script must be run as root" 1>&2
exit 1
fi
# name of primary network interface (before tunnel)
PRIMARY=eth0
# gateway ip address (before tunnel - adsl router ip address)
# automatically determine the ip from the default route
GATEWAY=`route -n | grep $PRIMARY | egrep "^0\.0\.0\.0" | tr -s " " | cut -d" " -f2`
# provided by tun2socks: interface name
TUNNEL=tun0
# If you'd like, putting the tun2socks command here is a good idea. It may or may not be necessary to do so, but either way is more convenient than running the two commands separately.
# iptables rules - important!
LOCAL_NET=192.168.0.0/16
#LOCAL_NET=$GATEWAY
# Flush all previous filter rules, you might not want to include this line if you already have other rules setup
iptables -t filter --flush
iptables -t filter -X MYVPN
iptables -t filter -N MYVPN
# Add local routes to routing table
route add -net 192.168.1.0 netmask 255.255.255.0 dev eth0
route add -host 23.21.163.237 dev eth0 gw 192.168.1.1
# Add ssh routes to routing table
ip route add table 128 to 192.168.1.0/24 dev eth0
ip route add table 128 default via 192.168.1.1
# Exceptions for local traffic & vpn server
iptables -t filter -A MYVPN -o lo -j RETURN
iptables -t filter -A MYVPN -o ${TUNNEL} -j RETURN
iptables -t filter -A MYVPN --dst 127.0.0.1 -j RETURN
iptables -t filter -A MYVPN --dst $LOCAL_NET -j RETURN
iptables -t filter -A MYVPN --dst ${SERVER} -j RETURN
iptables -t filter -A MYVPN --dst ${VPN_SERVER} -j RETURN
# Add extra local nets here as necessary
iptables -t filter -A MYVPN -j DROP
# MYVPN traffic leaving this host:
iptables -t filter -A OUTPUT -p tcp --syn -j MYVPN
iptables -t filter -A OUTPUT -p icmp -j MYVPN
iptables -t filter -A OUTPUT -p udp -j MYVPN
Oczywiście będziesz chciał, aby ten skrypt odzwierciedlał twoją konkretną sieć (np. Jeśli używasz czegoś w rodzaju podsieci 192.168.0.0/24, dostosuj odpowiednio). Ponadto jest bardzo ściśle oparty na skrypcie, którego używam z VPN, dlatego wszystkie wzmianki o MYVPN lub VPN - podczas gdy nie korzystasz z VPN, tun2socks
faktycznie zachowujesz się tak, jakbyś był, więc wszystko powinno działać tak samo.
Specjalne podziękowania za tę odpowiedź na Unix.SE za ukierunkowanie mnie we właściwym kierunku, aby odpowiedzieć na to pytanie.
Znowu EDYCJA: Wygląda więc na to, że OS X zrobiłby to ipfw
raczej z iptables (przepraszam, jestem głównie osobą z Linuksem i myślałem, że OS X ma dostępne iptables). Istnieją równoważności, które umożliwiają dostosowanie skryptu, z których niektóre zostały tutaj wskazane . man ipfw
powinien ustawić cię prosto na składnię. Zostawię oryginalny iptables
skrypt jako szablon, abyś mógł zobaczyć, co się dzieje koncepcyjnie. Wygląda na to, że WaterRoof może pomóc ipfw
w nieco bardziej przyjaznym dla użytkownika; inne interfejsy mogą być również dostępne.
tun2socks
nie wymaga SSH i serwera; przykład na ich stronie dotyczy użycia SSH do utworzenia proxy SOCKS. Jeśli masz już serwer proxy SOCKS, jest to całkowicie niepotrzebne. Tak, iptables
z mojej strony był to zły sposób. OS X, oparty na BSD, używa ipfw
raczej niż iptables
, co dotyczy jądra Linuksa. Jeśli chodzi o to, że jest skomplikowane, możesz znaleźć interfejs, który skonfiguruje go w łatwiejszy sposób, ale nie mam doświadczenia w tej kwestii. To, że jest skomplikowane na niskim poziomie, ma wiele wspólnego z tym, dlaczego jest tak zdolny do pracy.
ipfw
.
Dostępnych jest wiele rozwiązań. Żadne z nich nie jest tak proste jak zmiana niektórych ustawień: powodem jest to, że pokonuje to cały cel proxy, jakim jest kierowanie określonej aplikacji inną drogą (w celu ukrywania się, bezpieczeństwa, ochrony tożsamości ...) podczas opuszczania masz dostęp do (podobno szybszej) trasy lokalnej.
Niektóre mają zostać odrzucone z powodu twoich wymagań, ale pozwól mi tylko wspomnieć o nich dla kompletności: VPN, tunel SSH, użycie pfctl (filtr pakietów i interfejs kontroli NAT). Ponadto Tor, choć z pewnością nie jest przeznaczony do użytku, o którym myślisz, pozwala kierować cały ruch przez ich proxy.
Wszystkie te aplikacje są bezpłatne i wymagają co najmniej pewnej pomysłowości, aby je uruchomić. Z drugiej strony istnieją aplikacje płatne, w których większość pracy została wykonana przez kogoś innego, choć za pewną cenę.
umożliwia przekierowanie połączeń sieciowych komputera za pośrednictwem serwerów proxy. Możesz powiedzieć ProxyCap, które aplikacje będą łączyć się z Internetem za pośrednictwem serwera proxy i pod jakimi warunkami. Odbywa się to za pośrednictwem przyjaznego interfejsu użytkownika, bez potrzeby ponownej konfiguracji żadnego z klientów internetowych
Alternatywnie, istnieje Proxifier dla komputerów Mac (ostrożnie: obsługuje tylko do wersji 10.8). który
umożliwia aplikacjom sieciowym, które nie obsługują pracy za pośrednictwem serwerów proxy, działanie przez proxy i łańcuchy SOCKS lub HTTPS.