przekierowanie portu ssh ze zdalnej lokalizacji do komputerów w sieci serwera

Polowałem na wszystkie intersieci i nie mogę znaleźć prostego przykładu formy przekierowania portów, której szukam. Cóż, prawda jest taka, że po prostu nie zrozumiałem używanego żargonu, a potem przeoczyłem prawidłowe rozwiązanie.

Oto proponowana konfiguracja. Mam komputer w domu ( homeC ) i zazwyczaj łączę się z serwerem w pracy ( workServer.com ), ale ilekroć łączę się z serwerem, generalnie (90% czasu) po prostu przeskakuję na inny komputer w sieci ( localC 192.168.x.y). Bardzo chciałbym się ustawić workServer.com przesyłać dalej do innych adresów IP lokalnych komputerów, jeśli używam niestandardowego portu (np. 12345).

Załóżmy, że wszystkie zaangażowane komputery używają jakiegoś wariantu do unixa, ale użytkownik ma dostęp do roota tylko na niektórych komputerach (nie workServer.com ). W rzeczywistości nazwa użytkownika użytkownik jest taki sam na wszystkich komputerach. Próbuję znaleźć sposoby rozwiązania następujących problemów:

polecenie do użycia w workingServer.com który przekaże port do danego komputera lokalnego (muszę też wiedzieć, które porty są dostępne)
polecenie do uruchomienia homeC połączyć się localC

Na marginesie, byłoby interesujące, gdyby możliwe było ograniczenie adresów mac komputerów, z którymi można się połączyć użytkownik @ workingServer.com ponieważ widzę, że to znacznie zwiększa moje bezpieczeństwo.

Jeśli masz jakieś inne pomysły lub przydatne sugestie, byłbym bardzo wdzięczny.

ssh unix port-forwarding

— scicalculator
źródło

Odpowiedzi:

Tunelowanie byłoby odpowiednim terminem, jeśli łączysz się z SSH.

putty.exe -ssh username@publicip -pw password -L localport:privateip:destinationport

na przykład, gdybym tunelował przez SSH do portu 80 na komputerze o adresie 192.168.1.15 za publicznym adresem IP xxx.xxx.xxx.xxx, na którym znajduje się serwer SSH, zrobiłbym następujące czynności:

putty.exe -ssh username@xxx.xxx.xxx.xxx -pw password -L 8080:192.168.1.15:80

Mogłabym wtedy otworzyć przeglądarkę internetową na 127.0.0.1:8080 i wyżej, by poparzyć wszystko, co jest obsługiwane na porcie 80 na zdalnej maszynie.

— MaQleod
źródło

Wielkie dzięki za twój post. Po przeczytaniu kilku innych rzeczy i obejrzeniu twojego posta, myślę, że prawie mnie to doprowadza do tego, gdzie chcę być. Najpierw na homeC biegnę $ ssh workServer.com -L 2020:192.168.x.y:22, co mnie naprawdę zabiera workServer , ale mogę biegać w innej powłoce ssh -p 2020 localhost żeby mnie wyciągnąć homeC do 192.168.x.y (na workServer). Jest to raczej wygodne, ale czy istnieje sposób na powstrzymanie pierwotnego polecenia od przeniesienia mnie do serwera roboczego w terminalu (tj. Wykonanie tej czynności w tle, może linii w moim profilu bashowym?). Wielkie dzięki za radę

— scicalculator

@ dat5h: Potrzebujesz opcji -N, zobacz stronę podręcznika ssh.

— Jaap Eldering

@eldering, Dziękuję bardzo. Właśnie teraz mam $ ssh -N workServer.com -L 12345:192.168.x.y:22 &i wydaje się, że działa świetnie! Wielkie dzięki dla was obu.

— scicalculator

Chciałem tylko przyjechać i dać ostateczne rozwiązanie, które wybrałem. Następujące dwie linie będą dobrze działać w skrypcie powłoki, a z powodu „uśpienia 60” automatycznie rozłączą port, gdy odłączę się od przekazanej sesji. Ponadto otworzy to sesję tmux i zamknie połączenie ssh po odłączeniu (bardzo przydatne dla mnie :))

ssh -f2 -L $port:$localIP:22 workServer.com 'sleep 60' > /dev/null  2> /dev/null ; ssh -q -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -p $port localhost -t 'tmuxScript.sh'

. To połączenie rzeczy, które znalazłem w całej sieci i tutaj.

— scicalculator

Technologia, której szukasz, nosi nazwę „Network Address Translation” lub NAT w skrócie. Rozwiązanie jest specyficzne dla systemu operacyjnego. Zazwyczaj wymaga to zainstalowania lub aktywacji oprogramowania do routingu. Chcesz skonfigurować workServer.com jako router i użyć NAT do przekazywania portów. Jeśli workServer.com uruchomił FreeBSD, zrobiłbyś to http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-natd.html

Używałbyś firewalla do filtrowania adresów IP, a nie adresów mac. Albo użyłbyś tunelu ssh.

— Jay
źródło