Dlaczego odbiornik odwrotnego proxy SSH jest osiągalny tylko na serwerze
Sprawdź adres bindowania zdalnego odbiornika i tryb GatewayPorts, zanim zmienisz protokół proxy lub poświadczenia.
Zdalne przekazywanie może działać z serwera SSH, ale odmawiać połączeń z innej maszyny, ponieważ nasłuchuje tylko na loopbacku. Najpierw sprawdź rzeczywisty adres nasłuchu.
Po stronie serwera GatewayPorts | Bindowanie zdalnego przekazywania |
|---|---|
no, domyślnie | Ogranicza odbiorniki do loopbacku |
yes | Wymusza bindowanie wildcard |
clientspecified | Pozwala klientowi zażądać konkretnego adresu bindowania |
Dla odbiornika przeznaczonego dla jednego kontrolowanego interfejsu serwer może użyć:
GatewayPorts clientspecifiedNastępnie klient żąda odpowiedniego adresu w swojej specyfikacji -R. Ten adres musi istnieć na zdalnej maszynie, a inne ograniczenia przekazywania nadal obowiązują. Opcja -g po stronie klienta nie jest wymiennym mechanizmem sterowania dla tego kierunku.
Trzy uprawnienia pozostają odrębne: autoryzacja SSH do utworzenia przekazywania, dostęp sieciowy do jego odbiornika oraz własna polityka dostępu usługi HTTP lub SOCKS. Logowanie SSH uwierzytelnia twórcę tunelu; nie uwierzytelnia każdego późniejszego wywołującego współdzielony odbiornik ani nie dodaje wyzwania hasła SOCKS.
Jeśli zdalny wywołujący nadal nie może się połączyć, sprawdź w tej kolejności adres bindowania, ograniczenia przekazywania serwera i ścieżkę zapory. Gdy TCP dotrze do odbiornika, nieudane uzgadnianie proxy jest późniejszym problemem.