Dostęp do witryny HTTPS dostępnej tylko przez VPN za pomocą przekierowania SSH
Połącz jedną usługę HTTPS dostępną tylko przez VPN z lokalnym przekierowaniem SSH, zachowaj prawdziwą nazwę hosta dzięki --connect-to i wiedz, czego jedno przekierowanie TCP nie obejmie.
Jedna maszyna ma już zatwierdzony dostęp do VPN, druga potrzebuje dokładnie jednej prywatnej usługi HTTPS, a lokalne przekierowanie SSH może wypełnić tę lukę bez dawania drugiej maszynie tunelu. Przekierowanie przenosi jeden cel TCP zamiast całej sieci, i właśnie to ograniczenie jest sednem. Przejdź przez pięć kroków poniżej po kolei, ponieważ każdy zawodzi z innego powodu, a późniejszy krok nie uratuje wcześniejszej luki. Jeśli brakuje dowolnego warunku wstępnego, ten projekt go nie rozwiązuje i żadne dostrajanie poleceń nie pomoże.
Krok pierwszy: potwierdź trzy warunki wstępne
Trzy rzeczy muszą już być prawdziwe, zanim jakiekolwiek polecenie będzie miało znaczenie. Potrzebujesz zgody na używanie pierwszej maszyny jako hosta przekierowania, działającego dostępu SSH do niej oraz polityki serwera, która zezwala na zamierzony cel. Konto SSH utworzone do przesyłania plików może mieć wyłączone przekierowanie, a serwer, który zezwala na przekierowanie, nadal może ograniczać, które cele są przez nie osiągalne. Zapytaj przed testowaniem, ponieważ używanie stacji roboczej kolegi jako punktu przeskoku bez zgody jest problemem polityki, nawet gdy polecenie działa bezbłędnie.
Dwa polecenia rozstrzygają techniczną połowę tej listy. Pierwsze dowodzi, że konto i klucz działają bez interaktywnego monitu, a drugie wypisuje rzeczywistą politykę serwera zamiast zakomentowanego przykładu w pliku konfiguracji.
ssh -o BatchMode=yes [email protected] 'echo ok'
sudo sshd -T | grep -E 'allowtcpforwarding|permitopen'
Krok drugi: powiąż port loopback i utrzymaj sesję przy życiu
Na maszynie uruchamiającej aplikację klienta otwórz lokalne przekierowanie do prywatnej usługi. Powiąż je jawnie z loopback, aby nie było publikowane w sieci lokalnej, i wybierz wysoki port, którego nie zajmuje już żadna lokalna usługa. Utrzymuj sesję w działaniu, gdy pracujesz, ponieważ jej zamknięcie zamyka nasłuch. ExitOnForwardFailure zamienia odrzucone powiązanie lub zajęty port w natychmiastowe wyjście zamiast sesji, która pozostaje bez przekierowania, i to jest tryb awarii, który marnuje najwięcej czasu.
Prywatne połączenie jest nawiązywane z hosta przeskoku, więc jego DNS, trasy, polityka VPN i dostęp do usługi muszą wszystkie działać. Sesja SSH nie tworzy osiągalności, której host przeskoku nie ma, i nie naprawi trasy, której VPN nigdy nie wypchnął. Potwierdź nasłuch tam, gdzie naprawdę jest, zamiast ufać ciszy polecenia.
ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:9443:portal.lab.example:443 [email protected]
ss -ltn '( sport = :9443 )'
Krok trzeci: zachowaj nazwę HTTPS, gdy gniazdo jest lokalne
Przeglądanie https://127.0.0.1:9443/ zmienia nazwę serwera TLS i uprawnienia aplikacji. Certyfikat wydany dla portal.lab.example nie zostanie zweryfikowany wobec adresu loopback, a wynikowy błąd wygląda jak zepsuty certyfikat, a nie jak skrót przekierowania. Do testu z wiersza poleceń zachowaj prawdziwy URL i zmień tylko cel gniazda. To robi --connect-to, a podręcznik curl dokumentuje użyty poniżej format czterech pól.
curl --noproxy portal.lab.example --connect-to portal.lab.example:443:127.0.0.1:9443 https://portal.lab.example/
Nazwa pozostaje w URL, w uzgadnianiu TLS i w nagłówku Host, podczas gdy połączenie TCP idzie do lokalnego nasłuchu. Opcja bez pośrednika utrzymuje test na tym przekierowaniu, zamiast pozwolić skonfigurowanemu pośrednikowi HTTP go przechwycić, a pozostawienie włączonej weryfikacji certyfikatu jest tym, co czyni wynik sensownym.
Krok czwarty: wiedz, czego jedno przekierowanie nie obejmie
Jedno przekierowanie TCP obejmuje jeden port docelowy. Strona, która przekierowuje do drugiej nazwy hosta, ładuje zasoby z hosta wewnątrz sieci prywatnej lub wysyła na inny port, potrzebuje własnego przekierowania, a każde z nich wymaga tej samej kontroli polityki co pierwsze. Przepływy pracy przeglądarki dodają własne wymagania, ponieważ przeglądarce trzeba powiedzieć, aby wysyłała prawdziwą nazwę na lokalny port przez konfigurację pośrednika lub lokalne mapowanie. Udany test z wiersza poleceń nie dowodzi więc, że przeglądarka też sobie poradzi, choć dowodzi ścieżki.
UDP, wykrywanie SMB i logowanie do domeny w ogóle nie przechodzą przez przekierowanie TCP. Jeśli prawdziwym wymaganiem jest ogólny dostęp do sieci, ten projekt jest niewłaściwym narzędziem, a obsługiwana brama dostępu zdalnego jest właściwa.
Krok piąty: posprzątaj i zapisz
Zatrzymaj sesję, gdy test się skończy, i potwierdź, że nasłuch zniknął. Jeśli wybrany port był już zajęty, wybierz inny nieużywany port loopback i zaktualizuj razem URL, polecenie testowe i notatkę, zamiast zatrzymywać niepowiązaną lokalną usługę, aby zwolnić numer. Pozostawienie otwartego przekierowania na laptopie zamienia diagnostykę w niezarządzaną usługę.
Zapisz hosta przeskoku, przekierowany cel, lokalny port i kto zatwierdził ustalenie. Przekierowanie, które istnieje tylko w czyjejś historii powłoki, jest jedno uruchomienie od powtórnego śledztwa, a następna osoba nie będzie wiedzieć, który z trzech warunków wstępnych został już sprawdzony.