NetworkManager-ssh는 연결됨으로 표시하지만 아무것도 라우팅되지 않는다

메뉴는 SSH 연결을 활성으로 표시하고, 호스트 키는 받아들여졌으며, 브라우저는 여전히 도달해야 할 곳 어디에도 도달하지 못한다. 이것은 모순이 아니다. NetworkManager-ssh 프로필은 같은 호스트와 같은 키로 아주 다른 두 결과를 낼 수 있기 때문이다. 패킷을 나르는 터널 장치이거나, 특정 앱만 사용할 수 있는 전달 집합이다. 표시기는 관리되는 SSH 관계가 존재한다고 보고한다. 두 가지 중 무엇을 받았는지는 결코 보고하지 않는다.

메뉴 항목 하나 뒤에 있는 두 결과

두 모드 모두 같은 방식으로 인증하므로 서로 혼동된다. 같은 자격 증명으로 프로필을 똑같이 선택해도 라우팅할 수 있는 인터페이스가 남을 수도 있고, 한 앱에 알려야 하는 수신 소켓이 남을 수도 있다.

먼저 그 작업이 실제로 어느 결과를 필요로 하는지 정하라. 전체 서브넷 도달이 필요하면 장치가 필요하다. 원격 호스트의 단일 서비스에는 전달이 필요하며, 그것을 위해 터널을 만들면 보통 문제가 받을 만한 것보다 많은 라우팅 작업이 생긴다.

동작하기 전에 각 모드에 필요한 것

프로젝트는 두 모드를 모두 문서화하며, 전제 조건의 차이가 커서 하나가 빠지면 설계 선택이 아니라 프로토콜 실패처럼 보인다.

오른쪽 열을 주의 깊게 읽어라. 이런 티켓 대부분이 거기서 끝난다. 완벽하게 만든 터널 장치도 라우팅이 그 안으로 보내는 것만 덮고, 완벽한 전달도 그것을 쓰라고 들은 앱만 돕는다.

더미 인터페이스는 터널이 아니다

전달 모드에서 플러그인은 연결 모델을 충족하려고 만든 더미 인터페이스를 문서화한다. 관리자가 상태를 붙일 대상이 있도록 존재한다. 임의의 앱 패킷을 원격 네트워크로 나르지 않으며, 그 존재가 IP 라우팅이 바뀌었다는 것을 뜻하지 않는다.

프로젝트의 전체 터널 예시는 OpenSSH 터널 장치 지원에 관한 것이므로, 레이블의 터널이라는 단어는 능력을 서술하지 실제 정책이 아니다. 프로필 이름이 아니라 커널이 무엇을 할지 확인하라.

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

그다음 결과를 앱과 맞춰라. SOCKS를 이해하는 프로그램은 프록시를 쓰도록 구성해야 한다. 로컬 전달 소비자는 수신 주소를 지정받아야 한다. 둘 다 전달을 스스로 발견하지 못하며, 초록으로 바뀐 연결 표시기가 둘 중 어느 것도 돕지 않는다.

원격 쪽을 강요하지 말고 준비하라

일반 SSH 계정은 원격 터널 장치를 올릴 권한 없이도 인증할 수 있다. 프로젝트는 root 권한이 없는 경로를 문서화하는데, 관리자가 그 사용자를 위해 장치를 미리 만들고 클라이언트가 그에 맞는 번호를 고른다.

그런 배치는 서버의 터널 정책과 원격 네트워크의 주소를 소유한 쪽과의 조정이 필요하다. 장치를 만드는 것만으로는 리소스 경로도, 전달 권한도, 반환 경로도 주어지지 않으며, 예시 구성이 설득력 있어 보였다고 해서 그것들이 생기지 않는다.

해서는 안 되는 일은 예시를 돌리기 위해 무제한 전달이나 원격 root 로그인을 켜는 것이다. 운영자가 원격 네트워크 설정을 소유한 곳에서는 그 명령을 그 소유자에게 맡기는 지원되는 배치를 쓰고, 연결이 끊길 때 모순된 주소를 되돌리는 두 번째 도우미를 피하라.

인증의 맥락, 그리고 티켓에 적을 것

인증에는 고유한 맥락이 있다. 플러그인은 사용자 세션에 연결된 SSH 에이전트를 찾고 대상 호스트가 알려져 있을 것을 요구하므로, 한 터미널에서 동작하는 키가 관리자의 인증 경로에 자동으로 보이지는 않는다. 검사를 끄는 대신 승인된 절차로 호스트 키를 등록하고 확인받아라.

지원을 위해 네 가지를 기록하라. 플러그인과 버전, 선택한 모드, 의도한 원격 신원, 그리고 나타났어야 할 인터페이스나 수신 주소다. 그다음 앱의 진입점을 직접 시험하라. 연결 표시기와 동작하는 시험이 함께 있으면 증거이고, 연결 표시기만 있으면 SSH에 대한 진술이지 얻으려던 라우팅이나 리소스 권한에 대한 것이 아니다.