NetworkManager-ssh hlásí připojení, ale nic se neroutuje

Nabídka zobrazuje připojení SSH jako aktivní, klíč hostitele byl přijat a prohlížeč přesto nedosáhne ničeho, čeho měl dosáhnout. To není rozpor, protože profil NetworkManager-ssh může ze stejného hostitele a klíče vytvořit dva docela různé výsledky: tunelové zařízení, které přenáší pakety, nebo sadu přesměrování, kterou mohou používat jen některé aplikace. Indikátor hlásí, že spravovaný vztah SSH existuje. Nikdy nehlásí, který ze dvou výsledků jste dostali.

Dva výsledky za jednou položkou nabídky

Oba režimy se autentizují stejně, a právě proto se pletou. Výběr profilu úplně stejně, se stejnými pověřeními, vás může nechat s rozhraním, přes které lze routovat, nebo s naslouchajícím socketem, o kterém je třeba jednu aplikaci informovat.

Začněte rozhodnutím, který výsledek úloha skutečně potřebuje. Požadavek na dosažitelnost celé podsítě potřebuje zařízení. Jediná služba na vzdáleném hostiteli potřebuje přesměrování a stavět kvůli ní tunel obvykle vytvoří víc práce s routováním, než si problém zasloužil.

Co musí každý režim mít, než začne fungovat

Projekt dokumentuje oba režimy a předpoklady se natolik liší, že chybějící jeden vypadá jako selhání protokolu, nikoli jako rozhodnutí o návrhu.

Čtěte pozorně pravý sloupec, protože tam končí většina těchto tiketů. I dokonale postavené tunelové zařízení pokrývá jen to, co do něj routování pošle, a i dokonalé přesměrování pomůže jen aplikacím, kterým bylo řečeno, aby ho používaly.

Fiktivní rozhraní není tunel

V režimu přesměrování plugin dokumentuje fiktivní rozhraní vytvořené, aby splnilo model připojení. Existuje proto, aby měl správce k čemu připojit stav. Nepřenáší libovolné pakety aplikací do vzdálené sítě a nic v jeho přítomnosti neznamená, že se IP routování změnilo.

Příklady plného tunelu v projektu se týkají podpory tunelového zařízení OpenSSH, takže slovo tunel v popisku označuje schopnost, ne vaši skutečnou politiku. Ověřte, co udělá jádro, a ne jak se profil jmenuje.

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

Potom výsledek spárujte s aplikací. Program, který rozumí SOCKS, musí být nakonfigurován, aby proxy používal. Uživatel lokálního přesměrování musí být nasměrován na svůj naslouchač. Ani jeden přesměrování sám neobjeví a ani jednomu nepomůže indikátor připojení, který zezelenal.

Připravte vzdálenou stranu, místo abyste ji nutili

Běžný účet SSH se může autentizovat bez jakéhokoli oprávnění zvednout vzdálené tunelové zařízení. Projekt dokumentuje cestu bez rootu, kdy správce zařízení pro daného uživatele předem vytvoří a klient pak zvolí odpovídající číslo.

Takové uspořádání vyžaduje koordinaci s tunelovou politikou serveru a s tím, kdo vlastní adresování ve vzdálené síti. Vytvoření zařízení samo o sobě nedává trasy k prostředkům, oprávnění k přesměrování ani zpáteční cestu, a nic z toho nepřijde proto, že ukázková konfigurace vypadala přesvědčivě.

Co byste neměli dělat, je povolit neomezené přesměrování nebo vzdálené přihlášení roota, aby ukázka fungovala. Kde operátor vlastní nastavení vzdálené sítě, použijte podporované uspořádání, které tyto příkazy nechá na tomto vlastníkovi, a vyhněte se druhému pomocníkovi, který při odpojení obnovuje konfliktní adresy.

Kontext autentizace a co uvést v tiketu

Autentizace má vlastní kontext. Plugin hledá SSH agenta spojeného s uživatelskou relací a vyžaduje, aby byl cílový hostitel znám, takže klíč, který funguje v jednom terminálu, se automaticky nezpřístupní autentizační cestě správce. Nechte klíč hostitele zapsat a zkontrolovat schváleným postupem, místo abyste kontrolu vypínali.

Pro podporu si poznamenejte čtyři věci: plugin a verzi, zvolený režim, zamýšlenou vzdálenou identitu a rozhraní nebo naslouchač, který se měl objevit. Potom otestujte vstupní bod aplikace přímo. Připojený indikátor spolu s fungujícím testem je důkaz; samotný připojený indikátor je tvrzení o SSH, ne o routování nebo oprávnění k prostředku, které jste se snažili získat.