1.3. Architektura typu host-to-host
Architektura typu host-to-host łączy dwa krańcowe punkty bez pośrednictwa bramy VPN. Jest ona rzadko stosowana, zwykle wtedy, gdy jeden lub więcej administratorów potrzebuje zdalnie zarządzać urządzeniem sieciowym. W takim przypadku stacja robocza administratora lub serwisanta zostaje skonfigurowana jako klient VPN, a zarządzające urządzenie jako serwer VPN. Architektura tego typu została przedstawiona na rysunku 1.3.
Rysunek 1.3. Architektura host-to-host.
W chwili, gdy użytkownik chce połączyć się z zarządzanym serwerem musi zostać uwierzytelniony. Klient i serwer wymieniają informacje uwierzytelniające i połączenie zostaje nawiązane. Od tej chwili użytkownik może korzystać z serwera, a połączenie jest zabezpieczone przez VPN [2].
Architektura typu host-to-host jest jedyną, która chroni przesyłane dane na całej trasie przepływu - od stacji roboczej użytkownika aż do serwera. Może to być powodem różnych problemów. Urządzenia, np. firewall, sprawdzające zawartość pakietów mogą wtedy niepoprawnie wykonywać swoje funkcje, jeśli połączenie VPN jest szyfrowane. Z tego powodu, architektura tego typu wykorzystywana jest przede wszystkim tam, gdzie niewielka liczba zaufanych osób musi zdalnie zarządzać jakimś serwerem.
Architektura host-to-host jest pracochłonna w zakresie implementacji i utrzymania. Nie jest ona przezroczysta ani dla użytkowników, ani dla serwerów. Zarówno stacja robocza użytkownika jak i sam serwer muszą mieć zainstalowane i poprawnie skonfigurowane oprogramowanie umożliwiające połączenie VPN.
1.4. Ogólny opis środowiska systemowegoW niniejszej pracy zostanie przedstawiona koncepcja połączenia centrali z oddziałem firmy. Będzie to firma handlowa posiadająca centralę w Warszawie oraz jeden oddział w Gdańsku. Z uwagi na fakt, że w Warszawie będzie znajdował się serwer z programem handlowym, aby umożliwić pracownikom w oddziale przesyłanie danych w bezpieczny sposób konieczne jest zestawienie połączenia VPN pomiędzy Warszawą a Gdańskiem. Dzięki temu handlowcy z oddziału będą łączyć się poprzez przezroczysty tunel ze zdalnym pulpitem w centrali aby móc pracować na programie handlowym w centrali. Poprzez kanał VPN będą przesyłane jedynie wyniki działania programu. Dodatkowo dostęp do Internetu i pozostałych usług dla pracowników w Gdańsku będzie realizowany za pośrednictwem tunelu VPN poprzez łącze w centrali - DSL 1Mbit.
W koncepcji wykorzystano oprogramowanie OpenVPN, które działa w oparciu o protokół SSL. W obu lokalizacjach będą znajdować się routery pracujące w systemie Linux. Będą one pełnić rolę bramy SSL. Dodatkowo router w centrali zostanie tak skonfigurowany, że będzie pełnił funkcję firewalla, dzięki któremu odbywać się będzie autoryzacja użytkowników z oddziału - przyznanie dostępu do określonych usług (serwerów). Dla osób pracujących w centrali dostęp do usług realizowany będzie za pomocą list dostępowych konfigurowanych na routerze (bramie SSL).
Wejście do strefy zdemilitaryzowanej, w której znajdują się serwery zabezpieczony będzie czytnikiem biometrycznym. Dostęp do tego pomieszczenia posiada tylko administrator sieci oraz serwisant. Schemat połączenia VPN pomiędzy centralą a oddziałem firmy przedstawia rysunek 1.4.
Rysunek 1.4. Schemat połączenia centrali z oddziałem firmy.
źródło:
[1]. Roland J. F., Newcomb M. J.: CCSP Cisco Secure VPN Exam Certification Guide, Cisco Press, Indianapolis 2003
[2]. Frankel S., Kent K., Lewkowski R. i inni: Guide to IPsec VPNs, Recommendations of the National Institute of Stadards and Technology, 2005,http://csrc.nist.gov/publications/nistpubs/800-77/sp800-77.pdf
http://blog.kacperos.pl/najlepsze-darmowe-uslugi-vpn/