NetworkManager-ssh wys verbind, maar niks word gerouteer
Die aanduiding bewys net dat die bestuurde SSH-verhouding bestaan. Gaan na of die inprop ’n tonneltoestel of ’n stel deurvoere gebou het, en toets dan die program se pad.
Die kieslys wys die SSH-verbinding as aktief, die gasheersleutel is aanvaar, en die blaaier bereik steeds niks van wat dit veronderstel was om te bereik nie. Dit is nie ’n teenstrydigheid nie, want ’n NetworkManager-ssh-profiel kan twee heel verskillende uitkomste uit dieselfde gasheer en sleutel lewer: ’n tonneltoestel wat pakkette dra, of ’n stel deurvoere wat net sekere programme kan gebruik. Die aanduiding rapporteer dat die bestuurde SSH-verhouding bestaan. Dit rapporteer nooit watter van die twee jy gekry het nie.
Twee uitkomste agter een kieslysinskrywing
Albei modusse verifieer op dieselfde manier, en dit is juis hoekom hulle verwar word. Om die profiel byte-vir-byte op dieselfde manier te kies, met dieselfde geloofsbriewe, kan jou met ’n koppelvlak laat wat jy kan deurroete, of met ’n luisterende sokkie waarvan een program ingelig moet word.
Begin deur te besluit watter uitkoms die taak werklik nodig het. ’n Vereiste vir bereikbaarheid van ’n hele subnet het ’n toestel nodig. ’n Enkele diens op ’n afgeleë gasheer het ’n deurvoer nodig, en om ’n tonnel daarvoor te bou skep gewoonlik meer roeteringswerk as wat die probleem verdien het.
Wat elke modus moet hê voordat dit werk
Die projek dokumenteer albei modusse, en die voorvereistes verskil soveel dat ’n ontbrekende een soos ’n protokolmisluiking eerder as ’n ontwerpkeuse lyk.
| 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 |
Lees die regterkolom noukeurig, want dit is waar die meeste van hierdie kaartjies eindig. Selfs ’n perfek geboude tonneltoestel dek net wat roetering daarin stuur, en selfs ’n perfekte deurvoer help net die programme wat ingelig is om dit te gebruik.
Die dummy-koppelvlak is nie ’n tonnel nie
In deurvoermodus dokumenteer die inprop ’n dummy-koppelvlak wat geskep is om aan die verbindingsmodel te voldoen. Dit bestaan sodat die bestuurder iets het om toestand aan te heg. Dit dra nie willekeurige programpakkette na die afgeleë netwerk nie, en niks aan sy teenwoordigheid impliseer dat IP-roetering verander het nie.
Die vol-tonnel-voorbeelde in die projek handel oor OpenSSH-tonneltoestelondersteuning, so die woord tonnel in ’n etiket beskryf ’n vermoë, nie jou effektiewe beleid nie. Kyk wat die kernel gaan doen eerder as wat die profiel genoem word.
nmcli connection show --active
ip -br link
ss -lntp | grep -E "1080|8080"Pas dan die resultaat by die program. ’n SOCKS-bewuste program moet opgestel word om die instaanbediener te gebruik. ’n Verbruiker van ’n plaaslike deurvoer moet na sy luisteraar gewys word. Nie een van hulle ontdek die deurvoer op sy eie nie, en nie een word gehelp deur ’n verbindingsaanduiding wat groen geword het nie.
Berei die afgeleë kant voor in plaas daarvan om dit te forseer
’n Gewone SSH-rekening kan verifieer sonder enige toestemming om ’n afgeleë tonneltoestel te begin. Die projek dokumenteer ’n nie-root-pad waarin ’n administrateur die toestel vooraf vir daardie gebruiker skep, en die kliënt kies dan die ooreenstemmende nommer.
Daardie reëling vereis koördinasie met die bediener se tonnelbeleid en met wie ook al adressering op die afgeleë netwerk besit. Om die toestel te skep verleen nie op sigself die hulpbronroetes, die deurvoertoestemmings of ’n terugpad nie, en niks daarvan kom omdat die voorbeeldkonfigurasie oortuigend gelyk het nie.
Wat jy nie moet doen nie, is om onbeperkte deurvoer of afgeleë root-aanmelding te aktiveer om ’n voorbeeld te laat werk. Waar die operateur die afgeleë netwerkopstelling besit, gebruik die ondersteunde reëling om daardie opdragte aan daardie eienaar oor te laat, en vermy ’n tweede helper wat teenstrydige adresse by ontkoppeling herstel.
Verifikasiekonteks, en wat om in die kaartjie te sit
Verifikasie het sy eie konteks. Die inprop soek ’n SSH-agent wat met die gebruikersessie geassosieer is en vereis dat die bestemming se gasheer bekend is, so ’n sleutel wat in een terminaal werk, word nie outomaties sigbaar vir die bestuurder se verifikasiepad nie. Kry die gasheersleutel ingeskryf en nagegaan deur die goedgekeurde proses eerder as om die kontrole af te skakel.
Vir ondersteuning, teken vier dinge aan: die inprop en weergawe, die gekose modus, die beoogde afgeleë identiteit, en die koppelvlak of luisteraar wat moes verskyn het. Toets dan die program se ingangspunt direk. ’n Verbinde aanduiding plus ’n werkende toets is bewyse; ’n verbinde aanduiding alleen is ’n stelling oor SSH, nie oor die roetering of hulpbronvergunning wat jy probeer bekom het nie.