Centrum Szkoleniowe Idea4pro

Tunele ssh?

Klienta Secure Shell zazwyczaj wykorzystujemy do bezpiecznego, szyfrowanego dostępu do zdalnych urządzeń bądź zdalnego wykonywania poleceń na tych urządzeniach.

Stosunkowo mało znaną funkcją ssh jest możliwość konfiguracji tuneli ssh za pomocą których możemy uzyskać dostęp do zdalnego portu bądź użyć portu lokalnego by przesłać ruch z aplikacji do serwera.

Szybki rzut oka na manual klienta OpenSSH:

• Opcja -D
• Opcja -L

Scenariusz 1 – uzyskujemy dostęp do zasobów zdalnej sieci lokalnej

Załóżmy, że serwer ssh dostępny jest w publicznym Internecie i wspiera tunelowanie (forwarding). Za jego pomocą możemy uzyskać dostęp do innego urządzenia w zdalnej sieci LAN (urządzenie adresowane jest prywatnie i ukryte za NAT a router pośredniczący w połączeniu ma do niego dostęp).

Użyjemy opcji -L klienta OpenSSH. W dokumentacji możemy przeczytać:

Specifies that connections to the given TCP port or Unix socket on the local (client) host are to be forwarded to the given host and port, or Unix socket, on the remote side. This works by allocating a socket to listen to either a TCP port on the local side, optionally bound to the specified bind_address, or to a Unix socket. Whenever a connection is made to the local port or socket, the connection is forwarded over the secure channel, and a connection is made to either host port hostport, or the Unix socket remote_socket, from the remote machine.

Składnia jest następująca:

ssh user@host -L localport:privatehost:privateport

• user@host – użytownik i host, do którego się logujemy (ten, który będzie tunelował nasz ruch)
• localport – port lokalny na którym będzie nasłuchiwał ssh
• privatehost – host znajdujący się po “prywatnej stronie” (ten, do którego chcemy się dostać)
• privateport – port TCP hosta w sieci lokalnej, do którego chcemy się dostać (22,23,80 etc.)

Do dzieła:

$ ssh admin@public-host.com -L 22222:192.168.88.200:22

Powyższe polecenie zaloguje nas na host public-host.com. Jednocześnie otwierając na naszym laptopie port 22222 – od tego momentu cały ruch skierowany na localhost:22222 zostanie przetunelowany do hosta 192.168.88.200 na port 22 (oczywiście 192.168.88.200 musi być osiągalny z public-host.com!)

Teraz wystarczy uruchomić drugą sesję ssh (pierwszą utrzymujemy połączoną) w następujący sposób:

$ ssh -p 22222 admin@localhost

I jesteśmy w domu (czyli na 192.168.88.200).

Scenariusz 2 – wychodzimy na świat za pośrednictwem zdalnej sieci/hosta (proxy)

Ssh umożliwia także nieco inny sposób użycia tuneli. Możemy użyć serwera ssh jako serwera SOCKS. Jeśli przeglądarkę WWW skonfigurujemy tak by wykorzystywała wskazany przez nas lokalny port jako serwer SOCKS to wszystkie połączenia otwierane przez przeglądarkę będą forwardowane do serwera ssh i z jego źródłowym adresem IP będą podróżować przez Internet. Zerknijmy do dokumentacji:

Specifies a local “dynamic” application-level port forwarding. This works by allocating a socket to listen to port on the local side, optionally bound to the specified bind_address. Whenever a connection is made to this port, the connection is forwarded over the secure channel, and the application protocol is then used to determine where to connect to from the remote machine. Currently the SOCKS4 and SOCKS5 protocols are supported, and ssh will act as a SOCKS server. Only root can forward privileged ports. Dynamic port forwardings can also be specified in the configuration file.

Składnia polecenia to:

ssh user@host -D localport

• user@host – użytownik i host, do którego się logujemy (ten, który będzie tunelował nasz ruch)
• localport – lokalny port na którym nasłuchuje ssh i którego należy użyć w konfiguracji przeglądarki www

Do dzieła:

$ ssh admin@public-host.com -D 3000

I pora na konfigurację przeglądarki:

A gdzie w tym wszystkim MikroTik?

Jeśli próbowaliście powyższych przykładów przed dotarciem do tego miejsca, to oczywiście nie działają. MikroTik RouterOS domyślnie ma wyłączony forwarding ssh. Znowu szybki rzut oka na dokumentację:

Sub-menu:/ip ssh

forwarding-enabled (both | local | no | remote; Default: no)

to jest właśnie to.

admin@MikroTik > /ip ssh set forwarding-enabled=local

I to wszystko. Włączenie tej opcji pozwoli nam na zestawienie obu powyższych typów tuneli do routera MikroTik.

Jak widać, nawet bez skonfigurowanych usług VPN możemy zarówno uzyskać dostęp do zdalnej sieci lokalnej jak i “ukryć” się za zdalnym adresem IP korzystając z przeglądarki. Czy sposób jest skuteczny? Jak najbardziej. Czy wygodny? Niekoniecznie i właśnie dlatego nazwałem go VPN-em dla ubogich 🙂

ps. Popularny klient ssh dla Windows, putty – także umożliwia konfigurację tuneli

Chcesz lepiej poznać MikroTika? Ten i wiele innych tematów poruszanych jest nasz szkoleniu MTCSE.