Dlaczego dwa proxy SSH SOCKS pokazują ten sam publiczny IP
Zdiagnozuj identyczne publiczne wyjścia z kilku dynamicznych przekierowań SSH do tego samego serwera z wieloma adresami.
Dwie komendy, dwa lokalne porty SOCKS, jeden publiczny IP. To normalne, gdy oba połączenia SSH docierają do tego samego serwera, a serwer korzysta z tej samej zewnętrznej ścieżki sieciowej.
Adres używany do logowania przez SSH jest przychodzący. Połączenie z witryną to nowe połączenie wychodzące po stronie serwera lokalnego przekierowania dynamicznego. Te role są rozdzielone.
Podłączenie SSH najpierw do adresu A, a potem do adresu B na jednym VPS nie nakazuje mu używać A i B jako odpowiednich źródeł przekierowanych połączeń. Routing i wybór adresu źródłowego mogą wybrać to samo źródło dla obu.
Port lokalny to uchwyt, nie nowa tożsamość
Porty 1080 i 1081 rozróżniają nasłuchujące procesy na twoim laptopie. Nie przydzielają adresów zdalnych. Dokumentacja przekierowania dynamicznego wyjaśnia, jak cele otwierają się po stronie zdalnej, nie obiecując jednego adresu źródłowego na każdy adres logowania SSH.
Aby uzyskać osobne wyjścia, uczyń wybór jawnym w architekturze. Oddzielne bramy o różnych ścieżkach wychodzących to jedna opcja. Dedykowane proxy z udokumentowaną kontrolą źródła to druga. Kontrola adresu wychodzącego w Squidzie pokazuje, że jest to funkcja odrębna od przyjmowania połączenia klienta.
Lokalna opcja -b SSH nie jest selektorem zdalnego wyjścia. Wiąże połączenie SSH po stronie klienta, a nie źródło połączenia z witryną zdalnego serwera.
Sprawdź też rodzinę adresów i NAT. Witryna IPv6 może widzieć inną tożsamość niż witryna tylko IPv4, a kilka adresów serwera może być przetłumaczonych na jedno publiczne źródło. Licz użyteczne ścieżki wychodzące, nie tylko skonfigurowane porty czy adresy logowania SSH.