NetworkManager-ssh показує з’єднання, але нічого не маршрутизується
Індикатор доводить лише те, що керований зв’язок SSH існує. Перевірте, чи плагін створив тунельний пристрій або набір перенаправлень, а потім перевірте шлях застосунку.
Меню показує з’єднання SSH активним, ключ хоста прийнято, а браузер досі не досягає нічого з того, чого мав досягти. Це не суперечність, бо профіль NetworkManager-ssh може дати два цілком різні результати з одного й того самого хоста та ключа: тунельний пристрій, що переносить пакети, або набір перенаправлень, якими можуть користуватися лише певні застосунки. Індикатор повідомляє, що керований зв’язок SSH існує. Він ніколи не повідомляє, який із двох результатів ви отримали.
Два результати за одним пунктом меню
Обидва режими автентифікуються однаково, і саме тому їх плутають. Вибір профілю точно так само, з тими самими обліковими даними, може залишити вас або з інтерфейсом, через який можна маршрутизувати, або з прослуховуваним сокетом, про який треба повідомити один застосунок.
Почніть із рішення, який результат насправді потрібен завданню. Вимога доступності всієї підмережі потребує пристрою. Одній службі на віддаленому хості потрібне перенаправлення, а побудова для неї тунелю зазвичай створює більше роботи з маршрутизації, ніж проблема заслуговувала.
Що має мати кожен режим, перш ніж запрацює
Проєкт документує обидва режими, і передумови різняться настільки, що відсутня виглядає як збій протоколу, а не як проєктне рішення.
| 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 |
Уважно прочитайте правий стовпець, бо саме там закінчується більшість таких заявок. Навіть бездоганно побудований тунельний пристрій охоплює лише те, що маршрутизація надсилає в нього, і навіть ідеальне перенаправлення допомагає лише тим застосункам, яким сказано ним користуватися.
Фіктивний інтерфейс — не тунель
У режимі перенаправлення плагін документує фіктивний інтерфейс, створений для задоволення моделі з’єднання. Він існує, щоб менеджеру було до чого прикріпити стан. Він не переносить довільні пакети застосунків до віддаленої мережі, і ніщо в його присутності не означає, що маршрутизацію IP змінено.
Приклади повного тунелю в проєкті стосуються підтримки тунельного пристрою OpenSSH, тож слово тунель у мітці описує можливість, а не вашу фактичну політику. Перевірте, що зробить ядро, а не як називається профіль.
nmcli connection show --active
ip -br link
ss -lntp | grep -E "1080|8080"Потім зіставте результат із застосунком. Програма, що розуміє SOCKS, має бути налаштована використовувати проксі. Споживач локального перенаправлення має бути скерований на свій прослуховувач. Жоден із них не виявляє перенаправлення сам, і жодному не допомагає індикатор з’єднання, що став зеленим.
Підготуйте віддалений бік, а не примушуйте його
Звичайний обліковий запис SSH може автентифікуватися без будь-якого дозволу піднімати віддалений тунельний пристрій. Проєкт документує шлях без root, коли адміністратор заздалегідь створює пристрій для цього користувача, а клієнт потім обирає відповідний номер.
Така схема потребує узгодження з політикою тунелів сервера та з тим, хто володіє адресацією у віддаленій мережі. Створення пристрою саме по собі не дає маршрутів до ресурсів, дозволів на перенаправлення чи зворотного шляху, і ніщо з цього не з’являється тому, що приклад конфігурації виглядав переконливо.
Чого робити не слід — це вмикати необмежене перенаправлення або віддалений вхід root, щоб приклад запрацював. Там, де оператор володіє налаштуванням віддаленої мережі, використовуйте підтримувану схему, щоб залишити ці команди тому власникові, і уникайте другого помічника, який під час від’єднання відновлює суперечливі адреси.
Контекст автентифікації та що писати в заявці
Автентифікація має власний контекст. Плагін шукає агент SSH, пов’язаний із сеансом користувача, і вимагає, щоб цільовий хост був відомий, тож ключ, що працює в одному терміналі, не стає автоматично видимим для шляху автентифікації менеджера. Зареєструйте й перевірте ключ хоста через схвалений процес, а не вимикайте перевірку.
Для підтримки запишіть чотири речі: плагін і версію, обраний режим, передбачувану віддалену ідентичність та інтерфейс або прослуховувач, який мав з’явитися. Потім перевірте точку входу застосунку безпосередньо. Під’єднаний індикатор разом з робочим тестом є доказом; сам під’єднаний індикатор — це твердження про SSH, а не про маршрутизацію чи дозвіл на ресурс, який ви намагалися отримати.