Lokalne przekierowanie SSH czy pełny VPN dla jednego ekranu Maca?

Musisz zobaczyć ekran jednego Maca z własnej maszyny, Mac stoi za hostem, do którego już możesz się połączyć przez SSH, a pytanie brzmi, czy to zasługuje na VPN. Zwykle nie. Jedno lokalne przekierowanie przenosi jeden port TCP przez sesję SSH, którą już masz, a dla jednego ekranu na jednym hoście to mniejszy i łatwiejszy do audytu układ niż trasowanie całej sieci.

Decydują o tym trzy warunki, a każdy z nich może popchnąć cię w stronę zarządzanego VPN.

Decydują o tym trzy warunki

Pierwszy to zakres: jedna usługa na jednym hoście albo wiele hostów i wiele portów. Drugi to to, czy każdy przeskok między bastionem a celem jest już zaufany, ponieważ SSH chroni tylko ten odcinek, który kończy. Trzeci to to, kto ma utrzymywać ten układ po tym, jak go zbudujesz, bo ręcznie zrobiony tunel zwykle przeżywa osobę, która go rozumiała. Nazwij tę osobę, zanim zaczniesz, i zapisz polecenie w miejscu, w którym będzie mogła je znaleźć. Nieudokumentowane przekierowanie to przyszły incydent z odroczoną datą rozpoczęcia.

Jeśli odpowiedzi brzmią „jeden”, „tak” i „ja, na razie”, przekierowanie jest właściwym narzędziem. Jeśli którakolwiek odpowiedź się zmieni, wspierany projekt dostępu zdalnego kosztuje w skali roku mniej niż przegląd incydentu po nieudokumentowanym tunelu.

Przekieruj jeden port, nie sieć

Lokalne przekierowanie otwiera nasłuch na twojej maszynie i przesyła każde połączenie przez serwer SSH do celu, który ten serwer może osiągnąć. Dla Maca, którego usługa udostępniania ekranu nasłuchuje na TCP 5900, i bastionu, który potrafi rozwiązać mac.corp.example, polecenie jest krótkie i celowo wąskie. Każda opcja w nim istnieje po to, by układ pozostał mały: bez powłoki, bez nasłuchu na wszystkich interfejsach, bez demona. Czytaj je jako deklarację zakresu, a nie przepis.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:15900:mac.corp.example:5900 [email protected]

Przypisanie nasłuchu do 127.0.0.1 trzyma go z dala od wszystkich innych interfejsów. To nie formalność: przekierowanie przypisane do wszystkich interfejsów zamienia twój laptop w otwarty przekaźnik do sieci firmowej dla każdego w tej samej kawiarni z Wi-Fi. Jeśli port jest już zajęty, wybierz inny wysoki port i zaktualizuj przeglądarkę; nie zatrzymuj niezwiązaną usługę, żeby przykład pasował.

Konto na bastionie także potrzebuje zgody na przekierowanie do tego celu. Niektóre utwardzone konfiguracje SSH całkowicie wyłączają przekierowanie portów, a inne ograniczają je dyrektywą permit-listen lub permit-open. Przeczytaj politykę serwera, zanim uznasz, że odrzucony kanał oznacza błędne hasło.

Co SSH szyfruje i gdzie się zatrzymuje

Sesja SSH chroni ruch z twojego Maca do bastionu, a przekierowanie przenosi protokół VNC wewnątrz tej sesji, nie rozumiejąc go. Gdy połączenie opuszcza bastion w stronę celu, nie jest już wewnątrz twojej sesji SSH. Jakakolwiek ochrona istnieje na tym ostatnim przeskoku, należy do protokołu celu i do własnych mechanizmów sieci prywatnej.

Dlatego prostego ostatniego przeskoku VNC nie należy opisywać jako szyfrowanego od końca do końca tylko dlatego, że pierwszy przeskok użył SSH. Opisz odcinki uczciwie: mocno od klienta do bastionu, a potem to, co obsługuje cel. Jeśli wymaganiem jest, by cała ścieżka była szyfrowana jednym mechanizmem, przekierowanie tego nie spełnia.

Uwierzytelnianie na celu to znowu osobna sprawa. Konto SSH nie daje logowania do macOS, a usługa udostępniania ekranu nadal prosi o własne dane i nadal stosuje własną listę dostępu. Lokalny nasłuch, który przyjmuje połączenie, niczego nie dowodzi co do tego, czy usługa zdalna wpuści sesję.

Kiedy pełny VPN jest właściwym wyborem

Wybierz VPN, gdy zadanie wymaga więcej niż jednego portu: funkcje zarządzania i raportowania Apple Remote Desktop używają dodatkowego ruchu TCP i UDP, którego jedno przekierowanie TCP nie przeniesie. Przekierowanie nie jest częściową implementacją całego produktu; to inne, mniejsze narzędzie.

Wybierz go, gdy kilku administratorów łączy się ze zmiennych miejsc, bo zarządzany profil rozprowadza trasy, dane logowania i politykę bez wymyślania przez każdego własnej linii poleceń. Wybierz go, gdy ścieżka audytu ma pokazać, kto z czym się połączył, ponieważ sesja SSH na użytkownika i wspólne lokalne przekierowanie zostawiają bardzo różne zapisy.

Wybierz go wreszcie wtedy, gdy sieć docelowa nie powinna być w ogóle osiągalna z laptopa bez własnej bramy organizacji. Osobiste przekierowanie omija tę bramę z założenia, i właśnie dlatego należy do rejestru zmian, a nie do historii powłoki.

Pozwól przekierowaniu głośno zawodzić

Użyj ExitOnForwardFailure=yes, aby nieudane przypisanie zatrzymało sesję, zamiast zostawiać powłokę, która wygląda na połączoną i niczego nie przekierowuje. Trzymaj włączoną weryfikację klucza hosta i przedkładaj klucz lub agenta nad hasło. Potem przetestuj dokładny URL, którego użyje przeglądarka, bo działająca sesja SSH i działające połączenie z ekranem to dwa różne wyniki.

Dla natywnego klienta na macOS przeglądarkę osiąga się przez lokalny URL: open "vnc://127.0.0.1:15900". Jeśli okno się otworzy, a zdalny host odrzuci uwierzytelnianie, tunel jest w porządku, a problem jest po stronie celu. Jeśli okno nigdy się nie otworzy, problem jest w nasłuchu lub porcie.

Zatrzymaj sesję, gdy skończysz, i zapisz port, bastion, cel i politykę konta. Przekierowanie, którego nikt nie udokumentował, po pół roku jest nieodróżnialne od tylnych drzwi, i to jest najsilniejszy argument, by trzymać je małe, nazwane i tymczasowe.