W sytuacjach jednorazowych lub okazjonalnych podejście ProxyCommand jest bardzo wygodne.
Z drugiej strony, jeśli potrzebujesz kilku równoczesnych połączeń lub być może musisz często używać tego polecenia do codziennej pracy, możesz zamiast tego rozważyć ustawienie reguły translacji adresów sieciowych (NAT) na serwerze.
Wymaga to root
dostępu administratora (zwykle ) na serwerze, aby najpierw zastosować jedną regułę NAT. Zauważ, że może nie być dozwolone (lub skuteczne) stosowanie reguły NAT, nawet jeśli masz dostęp administratora, jeśli twój „serwer” jest w rzeczywistości kontenerem (takim jak Docker) zamiast maszyny.
Mówiąc o typowym systemie Linux z iptables
pakietem, reguła NAT stosowana na serwerze 1 w przykładowym przypadku może wyglądać następująco:
iptables -t nat -I POSTROUTING -d <server2-ip-address> -p tcp --dport <server2-port> -j SNAT --to :33101-33109
Że komenda instruuje jądro Linux, aby wszystkie połączenia w kierunku portu server2 portu z server2 adres-IP- wyjść przy użyciu portu źródłowego wybranego w zakresie 33101-33109, który jest dostępny w tym momencie.
Po wprowadzeniu tej reguły łączysz się ze swoim serwerem2 zwykłymi:
ssh username@server2 -p remote_port
i możesz używać tej samej ssh
komendy jednocześnie tyle razy, ile potrzebujesz, o ile są dostępne porty w zakresie określonym w regule NAT.
Należy jednak zauważyć, że netstat
(lub równoważne polecenie) uruchomione na serwerze zgłasza, że lokalny adres połączenia jest niezmodyfikowanym , losowo wybranym numerem portu źródłowego, nawet jeśli rzeczywisty ruch dostarczany na serwer2 niesie zmodyfikowany numer portu źródłowego.
Aby cofnąć regułę NAT, polecenie jest takie samo, z wyjątkiem -D
opcji zamiast -I
.
Automatyczne stosowanie reguły NAT podczas rozruchu zależy od tego, jaką dystrybucję Linuksa masz na serwerze i od tego, czy ma już jakąś konfigurację zapory ogniowej, czy nie.
Nie mam doświadczenia z systemami podobnymi do BSD, ale ufam, że istnieje odpowiednik.