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