NetworkManager-ssh arată conectat, dar nimic nu este rutat

Meniul arată conexiunea SSH ca activă, cheia gazdei a fost acceptată, iar browserul tot nu ajunge nicăieri din ceea ce ar fi trebuit să ajungă. Nu este o contradicție, pentru că un profil NetworkManager-ssh poate produce două rezultate complet diferite din aceeași gazdă și aceeași cheie: un dispozitiv de tunel care transportă pachete sau un set de redirecționări pe care doar anumite aplicații le pot folosi. Indicatorul raportează că relația SSH administrată există. Nu raportează niciodată care dintre cele două a fost obținut.

Două rezultate în spatele unei intrări de meniu

Ambele moduri se autentifică la fel, și exact de aceea sunt confundate. Selectarea profilului exact la fel, cu aceleași credențiale, vă poate lăsa cu o interfață prin care se poate ruta sau cu un socket de ascultare despre care o aplicație trebuie informată.

Începeți prin a decide de care rezultat are nevoie de fapt sarcina. O cerință de acces la o întreagă subrețea are nevoie de un dispozitiv. Un singur serviciu pe o gazdă aflată la distanță are nevoie de o redirecționare, iar construirea unui tunel pentru el creează de obicei mai multă muncă de rutare decât merita problema.

Ce trebuie să aibă fiecare mod înainte de a funcționa

Proiectul documentează ambele moduri, iar precondițiile diferă atât de mult încât una lipsă arată ca o defecțiune de protocol, nu ca o alegere de proiectare.

Citiți cu atenție coloana din dreapta, pentru că acolo se termină majoritatea acestor tichete. Chiar și un dispozitiv de tunel construit perfect acoperă doar ceea ce rutarea trimite în el, iar chiar și o redirecționare perfectă ajută doar aplicațiile cărora li s-a spus să o folosească.

Interfața fictivă nu este un tunel

În modul de redirecționare, modulul documentează o interfață fictivă creată pentru a satisface modelul conexiunii. Ea există pentru ca managerul să aibă ceva de care să lege starea. Nu transportă pachete arbitrare ale aplicațiilor către rețeaua aflată la distanță, iar nimic din prezența ei nu implică faptul că rutarea IP s-a schimbat.

Exemplele de tunel complet din proiect privesc suportul pentru dispozitivul de tunel al OpenSSH, așa că cuvântul tunel dintr-o etichetă descrie o capacitate, nu politica efectivă. Verificați ce va face nucleul, nu cum se numește profilul.

nmcli connection show --active
ip -br link
ss -lntp | grep -E "1080|8080"

Apoi potriviți rezultatul cu aplicația. Un program care înțelege SOCKS trebuie configurat să folosească proxy-ul. Un consumator de redirecționare locală trebuie îndreptat către socket-ul său de ascultare. Niciunul dintre ele nu descoperă redirecționarea singur, iar niciunuia nu-i ajută un indicator de conexiune care a devenit verde.

Pregătiți partea îndepărtată în loc să o forțați

Un cont SSH obișnuit se poate autentifica fără nicio permisiune de a ridica un dispozitiv de tunel aflat la distanță. Proiectul documentează o cale fără root în care un administrator creează dispozitivul în avans pentru acel utilizator, iar clientul alege apoi numărul corespunzător.

O astfel de aranjare necesită coordonare cu politica de tunel a serverului și cu cel care deține adresarea în rețeaua aflată la distanță. Crearea dispozitivului nu acordă de la sine rutele resurselor, permisiunile de redirecționare sau o cale de întoarcere, și nimic din toate acestea nu apare pentru că configurația exemplu părea convingătoare.

Ce nu ar trebui să faceți este să activați redirecționarea nelimitată sau autentificarea root de la distanță pentru ca un exemplu să funcționeze. Acolo unde operatorul deține configurarea rețelei aflate la distanță, folosiți aranjamentul acceptat pentru a lăsa acele comenzi acelui proprietar, și evitați un al doilea ajutor care restaurează adrese contradictorii la deconectare.

Contextul autentificării și ce să puneți în tichet

Autentificarea are propriul context. Modulul caută un agent SSH asociat sesiunii utilizatorului și cere ca gazda de destinație să fie cunoscută, așa că o cheie care funcționează într-un terminal nu devine automat vizibilă pentru calea de autentificare a managerului. Faceți cheia gazdei înregistrată și verificată prin procesul aprobat în loc să opriți verificarea.

Pentru asistență, notați patru lucruri: modulul și versiunea, modul selectat, identitatea îndepărtată vizată și interfața sau socket-ul de ascultare care ar fi trebuit să apară. Apoi testați direct punctul de intrare al aplicației. Un indicator conectat împreună cu un test funcțional este o dovadă; un indicator conectat singur este o afirmație despre SSH, nu despre rutarea sau permisiunea de resursă pe care încercați să o obțineți.