Dostęp zdalny czy VPN typu site-to-site: co wybrać?

Podróżujący pracownik i oddział potrzebują różnych tuneli, a zły wybór daje projekt, który działa w laboratorium i zawodzi w pierwszy poniedziałek. Dostęp zdalny łączy urządzenie z bramą. Site-to-site łączy dwie bramy reprezentujące sieci. Poniższa lista kontrolna rozstrzyga, który z nich wymaganie naprawdę opisuje.

Kto się łączy i co stoi za łączącym się

W dostępie zdalnym oprogramowanie na laptopie lub telefonie zestawia tunel, a brama uwierzytelnia użytkownika, urządzenie albo oba, zanim przydzieli adres i trasy. W site-to-site połączenie nawiązują routery, zapory lub bramy chmurowe, a urządzenia za nimi korzystają ze zwykłego routingu zamiast klienta. Ta różnica decyduje, kto odpowiada za dostępność tunelu: urządzenie pracownika w pierwszym przypadku, zarządzane urządzenie w drugim. Decyduje też, czy uwierzytelnianie opisuje osobę, czy sieć.

Zatrzymaj się tutaj, jeśli wymaganiem jest, aby każda maszyna w jednym biurze docierała do drugiego biura bez konfiguracji na urządzenie. To site-to-site, a stos logowań dostępu zdalnego jest słabym zamiennikiem.

Adresowanie i droga powrotna

Zaplanuj odrębne zakresy lokalne i zdalne. Dwie lokalizacje mogą używać tej samej prywatnej podsieci, a wtedy projekt wymaga tłumaczenia lub przenumerowania, zanim routing stanie się jednoznaczny. Router domowy z tym samym zakresem co centrala stwarza ten sam problem jednemu pracownikowi zdalnemu. Nakładanie się jest wystarczająco częste, że jego sprawdzenie należy do pierwszej rozmowy.

Droga powrotna jest tak samo ważna jak droga wyjściowa. Serwer może odebrać żądanie i nadal nie mieć trasy z powrotem do sieci klienta.

Udokumentuj, który router zna prefiks zdalny, zwłaszcza w sieciach chmurowych i przy wielu bramach. Zielona ikona tunelu nie odpowie, czy cel ma działającą drogę powrotną, a ping w jedną stronę też nie. W dostępie zdalnym brama zwykle posiada trasę puli; w site-to-site każdy router pośredni przenoszący prefiks musi się zgodzić. Tłumaczenie może ukryć brakującą trasę, dopóki nie popsuje się aplikacja osadzająca adresy.

Wyjście do internetu to osobna decyzja

Prywatna osiągalność nie wymaga, aby tunel przenosił publiczne przeglądanie. Czy zwykły ruch webowy wychodzi przez bramę, jest drugą decyzją, podejmowaną dla każdego projektu i zapisywaną w profilu klienta lub w konfiguracji lokalizacji.

Tunel pełny i tunel dzielony odpowiadają na to pytanie, a nie na pytanie dostęp zdalny kontra site-to-site. Nazwy wewnętrzne wymagają odpowiedniego DNS w obu projektach, ponieważ publiczny resolver nie ma odpowiedzi na nazwę hosta prywatnego biura. Wypychanie resolvera i wypychanie trasy domyślnej to powiązane ustawienia, a zmiana jednego bez drugiego daje awarie wyglądające jak problemy z DNS.

Użyj topologii, aby zawęzić usterkę

Jeden wędrujący laptop traci dostęp u klienta, na swoim koncie lub w sieci lokalnej. Cały oddział traci dostęp na wspólnych ścieżkach i bramach.

Sprawdź najpierw zestawienie tunelu, potem trasy, potem dozwolony ruch, potem rozwiązywanie nazw, potem logowanie do aplikacji, i zatrzymaj się na pierwszym kroku, który zawiedzie.ip route get 10.60.8.15 odpowiada na pytanie o routing, zanim przeczytasz choć jeden log aplikacji. Ustawienia szyfrowania nie naprawiają błędu uprawnień do udostępnionego pliku, a działający ping nie dowodzi, że aplikacja jest autoryzowana. Utrzymanie stałej kolejności zapobiega przypadkowym zmianom konfiguracji, które z jednej awarii robią trzy.

Na koniec trzymaj definicje prosto, czytając materiały dostawcy: komercyjny serwer wyjścia do internetu to inna usługa niż prywatna brama firmy i nie daje żadnego dostępu do sieci tej firmy.