DNS przez tunel SSH

Chcę skonfigurować mój system OSX tak, aby cały ruch sieciowy był przesyłany przez tunel SSH.

W tym celu napisałem mały skrypt, a są nim następujące polecenia:

// setup tunnel
ssh -fN -D 1080 -p 22 user@remote

// start up redsocks
sudo redsocks -c /tmp/redsocks.conf -p /tmp/redsocks.pid

// forward all tcp traffic to tunnel
sudo ipfw add 0010 fwd 127.0.0.1,12345 tcp from me to any not dst-port 12345 not dst-port 1080 not dst-ip REMOTE_IP

Używam redsocks, aby utworzyć serwer proxy HTTP do mojego tunelu ssh (aby móc przekazać cały ruch TCP do niego przez ipfw), redsocks.conf wygląda następująco:

base {
    log_debug = on;
    log_info = on;
    log = "file:/tmp/redsocks.log";
    redirector = generic;
}
redsocks {
    local_ip = 127.0.0.1;
    local_port = 55660;
    ip = 127.0.0.1;
    port = 1080;
    type = socks4;
}

Wydaje się, że wszystko działa do tej pory, cały ruch TCP w moim systemie OSX odbywa się przez tunel ssh, ale problem dotyczy ruchu UDP i z tego powodu zapytania DNS nie działają.

Jak mogę uzyskać DNS na mojej lokalnej maszynie do pracy przez tunel SSH?

Twoja ipfw …linia przekazuje tylko ruch TCP. Może dodać następujący wiersz?

sudo ipfw add 0011 fwd 127.0.0.1,12345 \
                   udp from me \
                   to any not dst-port 12345 \
                          not dst-port 1080 \
                          not dst-ip REMOTE_IP

Dobrym pomysłem jest także dodanie set -x(do debugowania) i set -e(aby od razu zakończyć się niepowodzeniem, jeśli którekolwiek z poleceń się nie powiedzie).

• Ogólnie należy używać terminu „tunelowanie SSH” w odniesieniu do tun/ tapz SSH.
• Przekierowanie portów jest specyficzną formą tunelowania, ale w tym kontekście powinno być nadal określane jako „przekierowanie portów”.
• Nie używaj tunelowania SSH (jak w -oTunneli -oTunnelDevice), z wyjątkiem szybkich zadań ad-hoc.
  • TCP przez TCP to bardzo zły pomysł:
    • Dlaczego TCP przez TCP jest złym pomysłem
    • Zrozumienie protokołu TCP przez TCP: wpływ tunelowania protokołu TCP na przepływność i opóźnienie między końcami
  • UDP przez TCP nadmiernie zwiększa opóźnienie w aplikacjach, które normalnie z niego korzystają. Programy korzystające z UDP powinny mieć pełną kontrolę nad własną niezawodnością i kontrolą przeciążenia, tak jak ma to miejsce w przypadku RTP.
• DNS może wykorzystywać TCP jako transport. Nie jest ograniczony do UDP, ale jest to preferowany transport.

Zamiast tego użyć sshuttle ? sshuttle twierdzi, że poprawnie obsługuje DNS i TCP, bez zbędnego manipulowania - tylko --dnsopcja.

Skarpetki IME wydawały się trochę stare i niekochane. I tak naprawdę nie rozumiem tego użycia ipfw i redsocks.

Chciałbym jednak zauważyć, że SOCKS4 nie obsługuje tunelowania DNS, więc nie jestem zaskoczony, że masz problemy. Kolejne wersje SOCKS obsługują to, więc możesz na to spojrzeć. I najwyraźniej SSH może obsługiwać SOCKS5 .

Poza tym, czego już używasz, sSH pozwala na tunelowanie całego ruchu IP, niezależnie od stosowanego protokołu warstwy 4. Twój zdalny serwer musi mieć, PermitTunnel yesa klient musi poprosić o tunel zgodnie z Tunneldyrektywą. Następnie możesz użyć tego nowego łącza jako domyślnej bramy. Zobacz szczegółową instrukcję dla tunelu tutaj.