NetworkManager-ssh pokazuje połączenie, ale nic nie jest trasowane
Wskaźnik dowodzi tylko, że zarządzana relacja SSH istnieje. Sprawdź, czy wtyczka zbudowała urządzenie tunelowe, czy zestaw przekierowań, a następnie przetestuj ścieżkę aplikacji.
Menu pokazuje połączenie SSH jako aktywne, klucz hosta został zaakceptowany, a przeglądarka nadal nie dociera donikąd, dokąd miała dotrzeć. To nie sprzeczność, ponieważ profil NetworkManager-ssh może dać dwa zupełnie różne wyniki z tego samego hosta i tego samego klucza: urządzenie tunelowe przenoszące pakiety albo zestaw przekierowań, którego mogą używać tylko niektóre aplikacje. Wskaźnik informuje, że zarządzana relacja SSH istnieje. Nigdy nie informuje, który z dwóch wyników otrzymałeś.
Dwa wyniki za jednym punktem menu
Oba tryby uwierzytelniają się tak samo i właśnie dlatego się je myli. Wybranie profilu dokładnie w ten sam sposób, z tymi samymi danymi logowania, może zostawić interfejs, przez który można trasować, albo gniazdo nasłuchujące, o którym trzeba poinformować jedną aplikację.
Zacznij od decyzji, jakiego wyniku zadanie naprawdę potrzebuje. Wymóg osiągalności całej podsieci wymaga urządzenia. Jedna usługa na zdalnym hoście wymaga przekierowania, a zbudowanie dla niej tunelu zwykle tworzy więcej pracy przy trasowaniu, niż problem na to zasługiwał.
Co każdy tryb musi mieć, zanim zacznie działać
Projekt dokumentuje oba tryby, a wymagania wstępne różnią się tak bardzo, że brakujące wygląda jak awaria protokołu, a nie wybór projektowy.
| Mode | What must exist | What still has to be true |
|---|---|---|
| Tunnel device | Compatible TUN/TAP arrangement on both ends, permission, addressing | A route policy that actually sends the intended prefixes into it |
| Forwarding only | A chosen SOCKS, local-forward or remote-forward listener | A permitted destination path on the far side |
Przeczytaj uważnie prawą kolumnę, bo tam kończy się większość takich zgłoszeń. Nawet doskonale zbudowane urządzenie tunelowe obejmuje tylko to, co trasowanie do niego wysyła, a nawet doskonałe przekierowanie pomaga tylko aplikacjom, którym powiedziano, żeby go używały.
Interfejs fikcyjny nie jest tunelem
W trybie przekierowania wtyczka dokumentuje fikcyjny interfejs tworzony, aby spełnić model połączenia. Istnieje, żeby menedżer miał do czego przypiąć stan. Nie przenosi dowolnych pakietów aplikacji do sieci zdalnej i nic w jego obecności nie sugeruje, że trasowanie IP się zmieniło.
Przykłady pełnego tunelu w projekcie dotyczą obsługi urządzenia tunelowego OpenSSH, więc słowo tunel na etykiecie opisuje możliwość, a nie twoją rzeczywistą politykę. Sprawdź, co zrobi jądro, a nie jak nazywa się profil.
nmcli connection show --active
ip -br link
ss -lntp | grep -E "1080|8080"Następnie dopasuj wynik do aplikacji. Program rozumiejący SOCKS musi być skonfigurowany do korzystania z proxy. Użytkownik przekierowania lokalnego musi zostać skierowany do swojego gniazda nasłuchującego. Żaden z nich nie odkrywa przekierowania sam i żadnemu nie pomaga wskaźnik połączenia, który zrobił się zielony.
Przygotuj stronę zdalną, zamiast ją wymuszać
Zwykłe konto SSH może się uwierzytelnić bez żadnego uprawnienia do podniesienia zdalnego urządzenia tunelowego. Projekt dokumentuje ścieżkę bez roota, w której administrator tworzy urządzenie z góry dla tego użytkownika, a klient wybiera potem pasujący numer.
Takie rozwiązanie wymaga uzgodnienia z polityką tuneli serwera i z tym, kto zarządza adresacją w sieci zdalnej. Utworzenie urządzenia samo nie daje tras do zasobów, uprawnień przekierowania ani drogi powrotnej, i nic z tego nie pojawia się dlatego, że przykładowa konfiguracja wyglądała przekonująco.
Czego nie powinieneś robić, to włączanie nieograniczonego przekierowania albo zdalnego logowania root, żeby przykład zadziałał. Tam, gdzie operator zarządza konfiguracją sieci zdalnej, użyj obsługiwanego rozwiązania, aby zostawić te polecenia temu właścicielowi, i unikaj drugiego pomocnika, który przy rozłączeniu przywraca sprzeczne adresy.
Kontekst uwierzytelniania i co wpisać w zgłoszeniu
Uwierzytelnianie ma własny kontekst. Wtyczka szuka agenta SSH powiązanego z sesją użytkownika i wymaga, aby host docelowy był znany, więc klucz działający w jednym terminalu nie staje się automatycznie widoczny dla ścieżki uwierzytelniania menedżera. Zarejestruj i sprawdź klucz hosta przez zatwierdzony proces, zamiast wyłączać sprawdzanie.
Na potrzeby wsparcia zapisz cztery rzeczy: wtyczkę i wersję, wybrany tryb, zamierzoną tożsamość zdalną oraz interfejs lub gniazdo nasłuchujące, które powinno się pojawić. Następnie przetestuj bezpośrednio punkt wejścia aplikacji. Wskaźnik połączenia razem z działającym testem to dowód; sam wskaźnik połączenia to stwierdzenie o SSH, a nie o trasowaniu czy uprawnieniu do zasobu, które próbowałeś uzyskać.