Ekrany w tunelu

Bezpośrednie połączenie modemowe zakłada, że program zainstalowany na serwerze odbiera połączenia klienta. Wdzwanianie na serwer i ustanawianie połączenia TCP/IP najczęściej odbywa się przez kanał PPP (Point-to-Point-Protocol). Metoda nawiązywania połączenia jest prosta, a komunikacja nie jest zabezpieczona. Z kolei tunel VPN jest inicjowany przez klienta, który nawiązuje połączenie z serwerem VPN, uruchamia połączenie między interfejsem loopback a komputerem docelowym i ewentualnie odpowiednio ustawia zasady routingu (tak może działać tunelowanie SSH).

Niektóre rozwiązania uruchamiają dodatkowy interfejs sieciowy, przydzielając mu adres IP z sieci docelowej (LAN). Rozwiązania działające w ten sposób to m.in. Check Point VPN-1, tunele PPTP i IPsec stosowane w środowiskach Unix (np. FreeS/WAN,CIPE, SSH) oraz Windows (klient IPsec), a także np. Open VPN - wieloplatformowa aplikacja open source.

Rozwiązania wykorzystujące połączenia tunelowane mają następujące zalety:

• po zestawieniu połączenia komputer klienta może działać tak, jakby był w sieci lokalnej; można mieć jedną konfigurację; jest to szczególnie wygodne, gdy z siecią LAN łączą się zdalnie komputery przenośne;
• w przypadku aplikacji, w których duża część obliczeń jest wykonywana na stacji roboczej, zaś ilość przesyłanych łączem danych nie jest duża, takie rozwiązanie jest szybsze niż serwer terminalowy;
• jeśli tunel jest zestawiony i działa stabilnie, można za jego pośrednictwem uruchamiać aplikacje korzystające z dynamicznie przydzielanych portów, np. telefonię IP;
• dostępne są tego rodzaju rozwiązania open source, co pozwala dokonać inspekcji ich kodu źródłowego; przykłady to bardzo dobra aplikacja FreeS/WAN i prosty, ale zadziwiająco skuteczny program CIPE;

warto też zwrócić uwagę na projekt Open VPN.

Są też niedogodności:

• konieczne jest uzgodnienie planu adresacji między sieciami łączonymi tunelem, aby adresy po obu stronach się nie powtarzały, ponieważ wtedy tunelowanie nie będzie działać prawidłowo;
• w sieciach z tunelami występują problemy z translacją NAT na zaporach firewall, np. często kłopotliwa jest translacja protokołu GRE (Generic Routing Encapsulation) - bywa że połączenia te są blokowane;
• aplikacje klienckie dla różnych platform muszą być tworzone nieco inaczej, ponieważ muszą uwzględniać możliwości i ograniczenia konkretnej implementacji stosu TCP/IP; przykładowo, w systemach Windows, gdy w systemie jest instalowany dodatkowy (poza standardowo dostarczanym) interfejs tunelu, błąd sterownika czasami powoduje załamanie całego systemu operacyjnego (niebieski ekran);
• szyfrowanie dużego ruchu za pomocą bezpiecznego, ale skomplikowanego algorytmu (3DES w IPsec) wprowadza narzut na pasmo, a ponadto wymaga skomplikowanych obliczeń (po obu stronach), co przynosi opóźnienia w transmisji - niekiedy tak duże, że praca zdalna przestaje mieć sens;
• zapewnienie bezpieczeństwa tunelu jest bardzo istotnym zadaniem, gdyż w przypadku włamania sieć stoi otworem; włamywaczowi z innego kontynentu prościej skanować adresy IP i znaleźć serwer dostępowy VPN, niż znaleźć numer telefoniczny, pod który trzeba połączyć się modemem.

Mając zestawione w ten czy inny sposób połączenie TCP/IP, trzeba mieć możliwość połączenia się z maszyną docelową tak, by pracować na niej zdalnie. W tym celu wykorzystuje się odpowiednie aplikacje. Oto najpopularniejsze z nich:

1. usługi terminalowe: Microsoft Terminal Services, Citrix MetaFrame XP, Jetro (Jetro Platforms) oraz podobne projekty działające w środowisku Unix, a także wieloplatformowe rozwiązanie Tarantella;
2. wieloplatformowy prosty program VNC (open source);
3. PC Anywhere (Symantec);
4. GoToMyPC - komercyjna aplikacja zdalnego dostępu, której cechy stawiają ją w pierwszym rzędzie zaawansowanych tego typu rozwiązań (Citrix).

Wyżej wymienione rozwiązania zostaną omówione bardziej szczegółowo, ze wskazaniem zarówno zalet, jak i potencjalnych źródeł problemów.