Proxy

Pojęciem proxy określamy serwer pośredniczący w ruchu sieciowym. Nasłuchuje na wybranym gnieździe i przesyła ruch dalej. Odbiorca widzi, że to ruch z serwer proxy a nie z „prawdziwego” klienta. Dawnymi czasy proxy dla WWW były bardzo popularne ponieważ pozwalały zaoszczędzić cenne pasmo łącza do Internetu. Serwer proxy uruchamiało się na granicy swojej sieci LAN. Wiem bo kiedy byłem dostawca Internetu takowy proxy, a dokładnie Squid uruchomiłem.  Zasada proxy była taka: jak ktoś pobiera stronę WWW to proxy ją zapisuje w swoim buforze (RAM + dysk) i jeśli za chwilę inny użytkownik tej samej sieci będzie sięgał do Internetu po tą samą stronę to zostanie ona mu przesłana z proxy. Dzięki temu można było zaoszczędzić pasmo. Na początku mojej przygody bycia ISP miałem łącze DSL 1 MBps i dzieliłem go na 30 osób… Dziś ten sposób wykorzystania proxy już stracił sens ze względu na ogromne szybkości łącz jakie są dostępne, responsywne WWW, wideo na żądanie i inne treści multimedialne generowane dynamicznie. Pozostały oczywiście inne zalety takie jak: filtrowanie ruchu, podmiana adresu IP a tym samym geolokalizacji i inne.

Zasada działania proxy jest prosta: uruchamiamy jakiś proxy i na kliencie wpisujemy jego adres oraz port. Historycznie był to port 8080 TCP. Przykładem może być przeglądarka. W Firefox (jak i innych) mamy sekcję właśnie dla Proxy:

W tym wypadku każda strona jaka załaduje użytkownik będzie pobierana przez komputer 192.168.53.110. To może powodować problemy bo serwer WWW klienta będzie widział pod innym adresem. Oczywiście jeśli pracujemy w sieci z której na świat wychodzimy za pomocą NAT to adresu tegoż proxy nam nie zmienia. W każdym wypadku komputer klienta jest „za” proxy zatem jest to jakiś rodzaj filtra.

Tunel SSH + dynamiczne proxy

W przypadku SSH wykorzystamy ta funkcjonalność do czegoś innego. Wyobraźmy sobie, że pracujemy w sieci LAN, która ma dość rygorystyczne zasady filtrowania ruchu wychodzącego. Sieć nasza pozwala nam tylko na wybrane typy połączeń np: TCP port 443 i 22. Nic więcej. To jest możliwe, bo taka siec może posiadać swój wewnętrzny serwer DNS i w sumie nic więcej nie trzeba do brodzenia po Internecie. Co wtedy robić? Jak żyć? Oczywiście można odpalić VPN (TCP/443) ale co jak go nie mamy i nie wolno instalować? Z pomocą przyjdzie nam SSH! Wykonamy połączenie SSH do zewnętrznego serwera (oczywiście trzeba mieć takowy np. jakiś VPS albo w serwer domu) i przez ten serwer będziemy swobodnie korzystać z Internetu (nie tylko z www). Oczywiście jak sieć blokuje port 22 to trzeba to jakoś obejść ale to inny temat (port SSH na serwerze nie 22 ale 443, VPN itp.).

Schemat połączenia będzie wyglądał jak niżej:

 

Poniżej opis sieci i sytuacji:

• pracujemy na PC1, mamy tam zainstalowane ssh
• za jego pomocą łączymy się z serwerem ssh na zdalnej maszynie np. 83.123.87.23 (zwykłe połączenie ssh) ale z opcją utworzenie dynamicznego mapowania portu lokalnego (opcja -D), w tym przypadku na maszynie lokalnej, na jej  interfejsie pętli zwrotnej (ang. loopback) otwiera się port 8080.
• wszystko co wpada do portu 8080 jest przekazywane do maszyny zdalnego serwera ssh i stamtąd dopiero wysyłane dalej (do Internetu)
• na swojej przeglądarce konfigurujemy proxy: adres 127.0.0.1 (lokalny bo tu nasłuchuje ssh) i podajemy nasz port 8080
• teraz cały ruch z przeglądarki (nieważne na jaki IP, nieważne na jaki port) jest kierowany szyfrowanym tunelem SSH do zdalnego serwera i dopiero ta maszyna przesyła go dalej
• pamiętaj, że bazowe połączenie SSH jest wykonane na protokół i port TCP/22 na maszynie zdalnej – jeśli to masz w swojej sieci zablokowane to musisz kombinować zapewne z innym portem

Poleceniem dla ssh uruchomienie się w taki sposób jest

#ssh nazwa@adresIP -D port_lokalny

Co jest istotne: to rozwiązanie wymaga aby port docelowy 22 był „przepuszczany” na lokalnym firewall. Jeśli tak nie jest to można na zdalnej maszynie skonfigurować serwer SSH tak, aby nasłuchiwał na wybranym porcie np. 443 (oczywiście jeśli nie ma konfliktu z webserwerem).

#ssh nazwa@adresIP -D port_lokalny -p 443

Podobnie możemy użyć programu typu PuTTY, podajemy adres i port serwera SSH:

W sekcji Tunel wybieramy Dynamic i wpisujemy lokalny port na jakim SSH będzie nasłuchiwać:

Po kliknięciu w Add należy się połączyć (Open) i można korzystać z proxy socks. Jak sprawdzić czy przekierowanie ruchu działa:

#netstat -aon | find "8080"

Dla Linux:

#netstat -aon | grep 8080

Opcje -D pochodzi on dynamic ponieważ na tym etapie nie wiadomo z jakich portów będzie korzystała przeglądarka. Wszelkie porty są pakowane do tunelu pracującego na lokalnym porcie 8080 i dopiero na zdalnej maszynie są wysyłane w świat żądania danego adresu IP i portu. Takie rozwiązanie zapewnia dużą elastyczność i niezależność od zabezpieczeń czy ograniczeń sieci lokalnej.

Tunel

Tunel jest sposobem połączenia sieci komputerowych i systemów IT,  które nie znajdują się w tej samej lokalizacji (nie są podłączone do na przykład tego samego przełącznika) ale znajdują się w różnych lokalizacjach na przykład różnych lokalizacjach geograficznych. Tunel pozwala zatem na komunikację między tymi sieciami jak jakby były podłączone do jednego przełącznika lub routera zależnie od wybranej konfiguracji, tak jakby pracowały razem, lokalnie w jednej sieci. Poniżej koncepcja tunelu między dwoma firmami. Z perspektywy tunelu i jego użytkowników nie ma znaczenia jaką trasą w sieci Internet zostanie przesłany ruch. Tunel daje zatem wirtualne połączenie, taki wirtualny kabel. W tak utworzonym tunelu można przesyłać ruch między sieciami obu biur. Dla użytkowników będzie to wyglądało jakby wszyscy pracowali w tym samym miejscu.

Tunel oczywiście bazuje na uprzednio fizycznie zestawionych połączeniach po IP i jest z perspektywy sieci i oprogramowania pracującej w niej wirtualnym połączeniem Często bywa zupełnie przezroczysty i użytkownicy nie wiedzą że pracują w zdalnej sieci łączonej za pomocą tunelu.

Już tutaj widać, że tunel potrzebuje dwóch adresów IP do zestawienia. To muszą być adresy, które mogą się komunikować. Kolejno takim tunelem będzie przesyłany ruch sieciowy, w sumie dowolnego rodzaju.

Tunel GRE

Najprostszym przykładem jest tunel typu GRE (ang. General Routing Encapsulation), który z założenia nie szyfruje danych ale umożliwia transmisję dowolnego protokołu. Ta idea pozwala na przenoszenie przez Internet ruchu, który nie jest zgodny z jego zasadami transmisji np prywatnych adresów IP czy protokołów, które nie są obsługiwane. Tunel GRE pozwala także na przesyłanie ruchu rozgłoszeniowego czyli broadcast i ruchu multiemisyjnego czyli multicast, zatem można łączyć systemy które wymagają do swojej pracy tego typu ruchu na przykład niektóre protokoły routingu, protokół ARP (dla łączenia sieci po L2).

Tunelowanie bazuje na enkapsulacji tak jak w przypadku systemu Ethernet: dane z wyższych warstw modelu ISO-OSI są enkapsulowane w warstwach niższych. W tym wypadku datagram IP pakowany jest do ramki GRE a ta do datagramu IP. Ten wewnętrzny datagram to adresacja wewnętrzna ten zewnętrzny to zewnętrzna. Na tym bazuje tunel: jest zestawiony między dwoma interfejsami IP (np. publicznymi w sieci Internet) ale wewnątrz przenosi ruch IP między dwoma adresami prywatnymi. Te prywatne adresy to datagramy wewnętrzne a te publiczne to zewnętrzne.

Pakowanie czyli enkapsulacja ma miejsce na różnych poziomach warstw modelu sieciowego ISO OSI. Zapewnia to elastyczność konfiguracji i możliwość przesyłania dowolnego protokołu z dowolną adresacją przez sieci, które tych protokołów czy adresacji nie obsługują. Przykładem jest tunelowanie IPv6 w IPv4, tunelowanie adresów prywatnych w sieci Internet, tunelowanie protokołów obcych Internetowi. Do takich celów idealnie nadaje się tunel GRE. Pojawi się wtedy tunel w tunelu. Z punktu widzenia użytkownika jest on całkowicie przezroczysty i raczej jest konfigurowany na urządzeniach szkieletu sieci a nie na komputerze klienta zatem użytkownik sieci nawet o nim nie wie.

Tunel GRE możemy przedstawić jak niżej:

Zauważ, że zielone połączenie sięga od „wewnętrznego” interfejsu routera R1 do analogicznego w R2. To ważne aby zadziałało przekazywanie ruchu broadcast. W tym przypadku w routerze możemy ustanowić most (ang. bridge), do którego dodamy fizyczny inerface dla sieci wewnętrznej oraz dodatkowy, wirtualny interfejs będący punktem zaczepienia dla późniejszego tunelu GRE Ponieważ oba interfejsy będą w moście to jak coś :”wpadnie” jednym z nich to „wyleci” drugim. Takie działanie zapewni przezroczystą pracę i będzie można przesyłać między sieciami także ruch broadcast.

Most można przedstawić jak niżej:

Po lewej mamy most (urządzenie wirtualne) a w nim fizyczna kartę sieci LAN o nazwie eth0 oraz wirtualny interfejs (Lo 0 0 loopback czyli interfejs pętli zwrotnej). Oba są dodane do mostu zatem adres IP także ustawiamy na moście a nie na jednym z jego interfejsów składowych. Czerwona linia obrazuje połączenie tunelu GRE – łączy się on z interfejsem Lo, a że jest on w moście to cały ruch na Lo jest widoczny (kopiowany) do eth0. Top daje przezroczystość. To jeden ze sposobów tunelowanie przezroczystego. Tunel GRE jest bardzo przydatny ale nie szyfruje danych samodzielnie zatem zazwyczaj korzysta się z tuneli szyfrowanych, o czym napisano poniżej.

Tunel VPN

Kolejnym rozwiązaniem tunelowania jest VPN (ang. Virtual Private Networking) czyli  wirtualna sieć prywatna. Ten rodzaj tunelu opiera się na routingu czyli na adresach IP i nie przenosi ruchu rozgłoszeniowego czy multiemisyjnego. W związku z tym bardzo często wykorzystuje się w nim jeszcze drugi tunel, właśnie tunel GRE czyli tunel w tunelu. Z definicji łącze VPN jest tunelem, który samodzielnie szyfruje dane dzięki czemu zapewnia poufność informacji. Wyróżniamy różne rodzaje tuneli VPN: tryb punkt – punkt za pomocą którego możemy łączyć dwie lokalizacje, oraz tryb Remote Access czyli zdalny dostęp dla na przykład mobilnych pracowników.

Model Site-to-Site

Tunele VPN mogą być konfigurowane na urządzeniach sieci – w tym wypadku nie będą dla użytkownika widoczne (ani oprogramowaniu tunelu ani jego działanie). To najczęściej rozwiązania dla firm pragnących połączyć po IP (warstwa 3) zdalne lokalizacje firmy. W tym wypadku pracownicy obu lokalizacji mogą pracować jak gdyby przebywali w jednej sieci, w jednym biurze i będą mogli posługiwać się adresami IP z puli prywatnej jaka została ustawiona w firmie. To wlaśnie połączenie site-to-site.

Idea tunelu Site-toSite

Model Remote Access

Można także tunel VPN uruchamiać na urządzeniu użytkownika co wymaga już instalacji oprogramowania oraz posiadania konta w zdalnym systemie serwera VPN. To typ połączenia Remote Acces bo faktycznie służy do nawiązania zdalnych połączeń pracownika z firmą. Tego typu rozwiązań jest bardzo dużo. Darmowym jest OpenVPN Book.  Za jego pomocą możemy korzystać z darmowej sieci VPN, co daje nam głownie zaletę zmiany IP pod jakim widać nas w sieci Internet. Prędkości są niewielkie ale na testy czy do telemetrii wystarczy. Popularne VPNy dają szyfrowany dostęp do ich serwera a z tego miejsca dopiero użytkownik wychodzi na świat.  W tym wypadku ni chodzi o połączenie dwóch lokalizacji ani zdalny dostęp, a tylko o szyfrowanie transmisji (oczywiści tylko do systemu VPN) i zmianę adresu IP. Więcej o tym rozwiązaniu tutaj.

Idea tunelów Remote Access

Tutaj mamy jeden centralny system (powiedzmy serwer VPN) i to do niego łączą się niezależnie klienci. Dzięki temu każdy z nich może mieć dostęp do zasobów firmy w swoim biurze. Jeśli dostęp ma bazować na rozgłoszeniach wymagane będzie GRE a jeśli nawet na warstwie Lt to wymagany będzie tunel L2TP (ang. Layer 2 Tunneling Protocol). Dla większości zastosowań domowych i biznesowych w zupełności wystarczy zwykłe połączenie VPN bazujące na L3 czyli adresacji IP.

Tunel SSH

Jeszcze innym rodzajem tunelu jest połączenie SSH (ang. Secure Shell), zazwyczaj wykorzystywane do zdalnej administracji i pracy w konsoli na routerach, przełącznikach czy serwerach. Za pomocą połączenia ssh można tunelować ruch przez tak zwane tunelowanie portów. Połączenie ssh z natury jest szyfrowane więc i tutaj mamy szyfrowany tunel. W przypadku tuneli VPN oraz GRE wymagane jest utworzenie wirtualnych interfejsów, na bazie których połączenia tunelowe są zestawiane. Połączenie tunelowe SSH nie wymaga tego, po prostu logujemy się do zdalnego urządzenia i za pomocą odpowiednich opcji oprogramowania ssh konfigurujemy ruch między wybranymi portami.

Połączenia SSH nie wymagają uprawnień administratora a jedynie posiadania konta w systemie docelowym. Przykład tunelu SSH znajdziesz tutaj. Jeśli chodzi o przekierowywanie ruchu między portami oraz zabezpieczanie ruchu nieszyfrowanego (tunelowanie w SSH) to takie rozwiązanie często jest najszybsze i najbardziej elastyczne. Tunele SSH są niezwykle proste i przydatne zatem zostaną omówione w osobnych artykułach. W artykule Tunel SSH opisano pierwsze z rozwiązani prosty tunel ssh z przekierowaniem portu.

Protokoły

Zalecanym protokołem dla samego tunelu będzie UDP ponieważ jest szybszy niż TCP i ma mniejszy narzut administracyjny. Ewentualne zagubione pakiery naprawią warstwy wyższe (np. TCP kiedy będzie transmitowany takim tunelem). Jeśli wymagane jest połączenie TCP (np. bo po drodze jest firewall i nie akceptuje UDP) będziemy mieli ruch TCP w tunelu TCP. Przy dużym ruchu i gubieniu pakietów może pojawić się niekorzystne zjawisko „tunel meltdown” czyli dławienia się takiego ruchu. To wynika z działania protokołu TCP, który samodzielnie realizuje badanie utraconych pakietów i ponawia je (oprócz tego wymaga potwierdzeń dostarczonych porcji danych). W takim przypadku jeśli tunel utraci kawałek ruchu będzie ponawiał go oraz zmniejszał rozwmiar okna TCP. W tym momencie tego samego doświadczy ruch TCP wewnątrz tuneli i zrobi to samo. Tunel może się zatem =w takich sytuacjach zatykać.

Temat tuneli jest bardzo szeroki, a tutaj podano tylko wstępne informacje. Patrząc do RouterOS możemy zobaczyć wiele sposobów organizacji tuneli:

PPTP – Point to Point Tunneling Protocol

SSTP – Secure Socket Tunneling Protocol

L2TP – Layer 2 Tunneling Protocol

OVPN – Open VPN

PPPoE – Point to Point over Ethernet

To nie wszystko, bo jest jeszcze wiele innych sposobów organizacji tuneli (WireGuard, TailScale itd)

Przykłady tuneli na Cisco oraz RouterOS i Linux opisane są w innych artykułach.

Podsumowanie

Tunele to bardzo elastyczne rozwiązania, pozwalające w prosty (i często darmowy) sposób łączyć odległe sieci LAN. Sprawiają, że urządzenia i użytkownicy pracują jak gdyby przebywali w jednej lokalizacji. Pamiętaj też, że tunel nie zawsze jest szyfrowany. Tunel, choć może pozwalać na zmianę adresu IP pod jakim jest Twoja maszyna widoczna w Internecie, nie daje anonimowości! To głównie narzędzie techniczne zwiększające zasięg sieci lokalnej.

Czasem może przydarzyć się nam sytuacja kiedy musimy nawiązać połączenie przez sieć (LAN czy WAN) ze zdalną usługą, która nie jest szyfrowana. Przykładem może być serwer WWW nie wspierający szyfrowania, serwer baz danych, zdalny pulpit rodzaju VNC itp. Połączenie takie nie będzie bezpieczne ponieważ istnieje możliwość przechwycenia i oglądania nieszyfrowanego ruchu a tym samym naszych danych. W takich danych mogą być loginy, hasała lub inne dane wrażliwe. Sytuacja wygląda zazwyczaj tak:

W tym przykładzie na zdalnej maszynie mamy serwer Apache, który nie obsługuje szyfrowania. Z przeglądarki klienta łączymy się więc na port 80 serwera czyli wykonujemy połączenie nieszyfrowane. Cała treść transmitowana między klientem a serwerem stoi otworem dla ewentualnego napastnika. Zakładamy, że nasza usługa sieciowa pracuje na serwerze i jest dostępna na adresie IP i określonym porcie (TCP lub UDP, to nie ma teraz znaczenia). W naszym wypadku jest to serwer Apache i nasłuchuje na podanym adresie IP i porcie 80.

Poniżej przykład przechwyconego ruchu, w którym pobrano stronę WWW z serwera.

Jak widać cała treść strony jest dostępna. Co zatem zrobić aby w takie sytuacji podnieść bezpieczeństwo? Zakładamy, że nie możemy uruchomić szyfrowania naszej usługi sieciowej. Odpowiedzią jest: tunel SSH.

Tunel SSH na bazie putty (Windows)

Wykonamy z klienta Windows do serwera Linux (trzeba mieć na nim konto) połączenie szyfrowane SSH. Na bazie tego połączenia zostaną nieco zmodyfikowane porty z jakich będziemy korzystać. Przeglądarka internetowa wykonuje połączenie do serwera WWW z losowego, wysokiego portu klienta na port 80 serwera WWW (HTTP, połączenie nieszyfrowane). Jeśli chcemy taką transmisję zabezpieczyć to możemy zmienić konfigurację serwera aby nasłuchiwał na adresie lokalnym pętli zwrotnej serwera (127.0.0.1), port pozostanie ten sam choć możemy go zmienić. Nasłuchiwanie na adresie zewnętrznym (w naszym przykładzie 192.168.55.102) można wyłączyć. Efekt będzie taki, że teraz z sieci LAN/WAN nikt bezpośrednio nie dostanie się do usługi WWW co może podnieść bezpieczeństwo takiej usługi choć zależy od wymagań i sytuacji. Dostęp możliwy będzie jedynie z lokalnie uruchamianych programów (lokalnie czyli na serwerze). Jak zatem dostać się do usługi sieciowej? Rozwiązaniem jest właśnie Tunel SSH.

Z komputera klienckiego łączymy się tunelem SSH do serwera. Dodatkowo wykonamy „przekierowanie” gniazda 127.0.0.1:10000 z komputera klienckiego na gniazdo 127.0.0.1:80 serwera. Zapewni to zaszyfrowanie (za pomocą tunelu SSH) nieszyfrowanego ruchu WWW. Gniazdo 127.0.0.1:1000 oznacza, że teraz na komputerze klienckim program SSH nasłuchuje żądań przeglądarki na adresie pętli zwrotnej (127.0.0.1) na porcie 10000. Tutaj można podać dowolny port, ale nie kolidujący z usługą pracującą na komputerze klienckim.

Teraz klient SSH ze swojego adresu IP i losowego portu nawiązuje połączenie szyfrowane (ssh) do serwera SSH pracującego na maszynie zdalnej na jej adres IP (w naszym przykładzie 192.168.55.102) i na port, na którym zdalny SSH nasłuchuje (standardowo 22). Dodatkowo SSH przekieruje teraz port 10000 z komputera klienckiego na gniazdo 127.0.0.1:80 na maszynie zdalnej Na bazie takiego zaszyfrowanego połączenia wykonywane teraz może być nieszyfrowane połączenie WWW. Inaczej mówiąc SSH nasłuchuje teraz na komputerze klienckim na adresie 127.0.0.1 i porcie 10000. Wszystko co tam „wpadnie” zostanie wysłane tunelem SSH na port serwera WWW po drugiej stronie połączenia. W ten sposób można przekierować i zabezpieczyć dowolną usługę sieciową. Połączenie WWW zatem pracuje teraz na bazie połączenia (tunelu) SSH.

Procedura jest taka:
– najpierw nawiązujemy połączenie SSH klient -> serwer (z przekierowanymi portami)
– na bazie powyższego nawiązujemy połączenie w wybraną usługą sieciową pracującą na zdalnej maszynie

Konfiguracja putty:

a) Ustalamy adres serwera (z naszą usługą docelową i pracującym ssh)

b) Określamy na jakim porcie lokalnym (klient) nasłuchuje program putty (opcja Source port czyli niejako port  źródłowy dla połączenia w tunelu) oraz na jaki adres IP i port zdalny ma być ruch przekierowany z tego portu (opcja Destination, najczęściej będzie to adres pętli zwrotnej na maszynie zdalnej, do której się łączymy przez SSH)

c) klikamy Add, wracamy do sekcji Session, zapisujemy ją i łączymy się klikając Open

W oknie jakie się pojawi klikamy Tak aby zapisać elektroniczny odcisk palca serwera.

Kolejno trzeba się zalogować do SSH aby zestawić tunel

Od tego momentu aby połączyć się (tym razem już bezpiecznie) ze zdalną usługą wpisujemy w kliencie (w naszym przykładzie przeglądarka) adres pętli zwrotnej 127.0.0.1 i podany w putty port lokalny (tutaj 10000).

 

Tunel SSH na bazie ssh w konsoli (Linux)
Połączenie między systemami Linux wygląda następująco:

ssh superu@192.168.55.102 -L 10000:127.0.0.1:80

W podanym przykładzie „superu” to nazwa konta na maszynie zdalnej. Użyj swojej nazwy logowania. Opcja „-L” (jak local) dokonuje przekierowania lokalnego portu 10000 (możliwe, że na dowolnym interfejsie) na port 80 (zwany tu zdalnym) nasłuchujący na interfejsie pętli zwrotnej na maszynie zdalnej.

Uwaga: to polecenie włączy nasłuchiwanie na porcie 10000 maszyny lokalnej (źródłowej) ale na interfejsie loopback. Jeśli chcesz aby inne komputery mogły także nawiązywać połączenie z tą zdalną maszyną to musisz port ten przypisać do adresu 0.0.0.0. Wtedy będzie on dostępny dla innych hostów z sieci lokalnej komputera źródłowego. Zrobić to można włączając opcję ‚AllowGroups yes’ w pliku konfiguracyjnym sshd: /etc/ssh/sshd_config (trzeba przeładować sshd: sudo systemctl reload ssh). Włączona także musi być opcja AllowTcpForwarding.

Przykład wykorzystania tunelu ssh: zdalny pulpit
Tego typu tunel często wykorzystuje się do połączeń na zdalny pulpit kiedy aplikacja tego typu nie wspiera szyfrowania. Przykładem może być Tight VNC Server. Połączenie wygląda tak:

Zestawiamy tunel SSH z lokalnego komputera (klient) do zdalnego pod adres 192.168.0.1 i port 22. Na zdalnym komputerze działa VNC Server na gnieździe 127.0.0.1:5901 (częsta i domyślna konfiguracja). Tunel na komputerze lokalnym uruchamia nasłuchujący port np. 10000 (w putty zwany Source port bo to jest port źródłowy z którego ruch będzie wysłany na port a właściwie gniazdo docelowe, w putty opisane jako Destination). Teraz pracując na kliencie możemy uruchomić klienta VNC (nie wspierającego szyfrowania) i zalogować się na adres 127.0.0.1 (maszyna lokalna) i port 10000 (port źródłowy). Tunel cały ruch z tego portu przeniesie do maszyny docelowej (po ssh) i tam połączy się z adresem 127.0.0.1 na porcie 5901. Tak więc połączenie bazowe zestawione jest między 192.168.0.99 i port losowy a 192.168.0.1 port 22 (domyślny na ssh). Połączenie VNC bazujące na tym fundamencie zestawione jest między adresem pętli zwrotnej komputera lokalnego (klienta) i portem 10000 a adresem pętli zwrotnej komputera zdalnego i portem 5901. To, że po obu stronach tego „połączenia” występują identyczne adresy nie jest błędem ani problemem. Tunel ssh przekieruje ruch między portem źródłowym a docelowym co działa podobnie jak usługa NAT.

Dzięki powyższemu tunelowi możemy bezpiecznie połączyć się z usługą pracującą na zdalnej maszynie. Co ważne, nawet gdy ta usługa pracuje na adresie pętli zwrotnej takiej maszyny. Poniżej przykład łączenia się z VNC Server. Uprzednio został zestawiony tunel ssh i w jego ramach kolejno połączenie na port lokalny, które zostanie przetransportowane tunelem do maszyny zdalnej.

Podsumowując

Program SSH łączy się szyfrowanym połączeniem z hostem zdalnym, na którym pracuje pewna usługa. Najczęściej usługa taka nasłuchuje na wybranym porcie powiązanym z interfejsem pętli zwrotnej (ang. loopback) czyli na adresie 127.0.0.1. To jest natywny port wybranej usługi np. 80 dla WWW, 2289 dla RDP itd. Połączenie to też otwiera na lokalnym (źródłowym) hoście port podany w opcji -L (na interfejsie loopback i adresie 127.0.0.1) i przekierowuje z niech ruch do hosta zdalnego (szyfrowanym tunelem) do interfejsu loopback (adres 127.0.0.1) na wybrany w poleceniu port. Graficznie pokażemy to tak:

Poszczególne elementy:

superu@192.168.5.102 – logujemy sie do wybranej maszyny na konto ‚superu’

-L 10000 – otwiera lokalny port na interfejsie lokalnym 127.0.0.1

127.0.0.1:80 – gniazdo na hoście docelowym do jakiego będzie skierowany ruch z portu 10000 maszyny źródłowej

Zastosowanie

Podłączenie się do nieszyfrowanej usługi na zdalnym hoście za pomocą szyfrowanego tunelu.

Świetny opis innych możliwości ssh masz tutaj.