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, а не о маршрутизации или разрешении на ресурс, которое вы пытались получить.