Mac 화면 하나에는 로컬 SSH 전달이 맞을까, 전체 VPN이 맞을까

자신의 기기에서 Mac 한 대의 화면을 봐야 하고, 그 Mac은 이미 SSH로 접속할 수 있는 호스트 뒤에 있으며, 그것이 VPN을 쓸 만한 일인지가 문제다. 보통은 아니다. 로컬 전달 하나는 이미 가진 SSH 세션을 통해 TCP 포트 하나를 나르며, 호스트 하나의 화면 하나라면 네트워크 전체를 라우팅하는 것보다 작고 감사하기 쉬운 구성이다.

이를 결정하는 조건은 세 가지이며, 그중 어느 하나만 달라져도 관리형 VPN 쪽으로 가야 한다.

결정하는 세 가지 조건

첫째는 범위로, 호스트 하나의 서비스 하나인지, 여러 호스트와 여러 포트인지다. 둘째는 배스천과 대상 사이의 모든 홉이 이미 신뢰되는지로, SSH는 자신이 종료하는 구간만 보호하기 때문이다. 셋째는 이것을 만든 뒤 누가 이 구성을 지원할지로, 손으로 만든 터널은 그것을 이해한 사람보다 오래 사는 경향이 있다. 시작하기 전에 그 사람을 지목하고, 그가 찾을 수 있는 곳에 명령을 적어 두어라. 문서화되지 않은 전달은 시작일이 미뤄진 미래의 사고다.

답이 «하나», «예», «지금은 나»라면 전달이 맞는 도구다. 어느 답이든 바뀌면, 지원되는 원격 접속 설계가 일 년 기준으로 문서화되지 않은 터널 뒤의 사고 검토보다 저렴하다.

네트워크가 아니라 포트 하나를 전달하라

로컬 전달은 자신의 기기에 리스너를 열고, 각 연결을 SSH 서버를 거쳐 그 서버가 도달할 수 있는 목적지로 중계한다. 화면 공유 서비스가 TCP 5900에서 대기하는 Mac과, mac.corp.example을 확인할 수 있는 배스천이라면 명령은 짧고 의도적으로 좁다. 그 안의 모든 옵션은 셸 없음, 모든 인터페이스의 리스너 없음, 데몬 없음처럼 구성을 작게 유지하기 위해 있다. 조리법이 아니라 범위 선언으로 읽어라.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:15900:mac.corp.example:5900 [email protected]

리스너를 127.0.0.1에 묶으면 다른 모든 인터페이스에서 떨어져 있다. 이것은 형식이 아니라, 모든 인터페이스에 묶인 전달이 같은 카페 Wi-Fi에 있는 누구에게나 당신의 노트북을 사내 네트워크로 통하는 열린 중계로 만든다는 뜻이다. 포트가 이미 사용 중이면 다른 높은 포트를 골라 뷰어를 갱신하고, 예제에 맞추려고 무관한 서비스를 멈추지 마라.

배스천의 계정에도 그 목적지로 전달할 권한이 필요하다. 일부 강화된 SSH 설정은 포트 전달을 완전히 끄고, 일부는 permit-listen이나 permit-open 지시로 제한한다. 거부된 채널이 비밀번호가 틀렸다는 뜻이라고 단정하기 전에 서버 정책을 읽어라.

SSH가 암호화하는 것과 그것이 멈추는 곳

SSH 세션은 Mac에서 배스천까지의 트래픽을 보호하고, 전달은 VNC 프로토콜을 이해하지 않은 채 그 세션 안에서 나른다. 연결이 배스천을 떠나 대상으로 향하면, 그것은 더 이상 당신의 SSH 세션 안에 없다. 그 마지막 홉에 어떤 보호가 있든 그것은 대상 프로토콜과 사설 네트워크 자체의 통제에 속한다.

그래서 첫 홉이 SSH를 썼다는 이유만으로 마지막 VNC 홉을 종단 간 암호화라고 설명해서는 안 된다. 클라이언트에서 배스천까지는 강하고 그 뒤로는 대상이 지원하는 만큼이라는 식으로 구간을 정직하게 설명하라. 전체 경로가 하나의 메커니즘으로 암호화되어야 한다는 요구라면, 전달은 그것을 충족하지 못한다.

대상에서의 인증은 다시 별개의 문제다. SSH 계정은 macOS 로그인을 주지 않으며, 화면 공유 서비스는 여전히 자체 자격 증명을 요구하고 여전히 자체 접근 목록을 적용한다. 연결을 받아들이는 로컬 리스너는 원격 서비스가 세션을 받아들일지에 대해 아무것도 증명하지 않는다.

전체 VPN이 옳은 판단일 때

작업에 포트가 둘 이상 필요하면 VPN을 골라라, Apple Remote Desktop의 관리와 보고 기능은 TCP 전달 하나로는 나를 수 없는 추가 TCP와 UDP 트래픽을 쓰기 때문이다. 전달은 제품 전체의 부분 구현이 아니라, 다른 더 작은 도구다.

여러 관리자가 바뀌는 위치에서 접속한다면 VPN을 골라라, 관리형 프로필이 각자가 명령줄을 발명하지 않아도 경로, 자격 증명, 정책을 배포하기 때문이다. 감사 기록이 누가 무엇에 접속했는지 보여야 한다면 VPN을 골라라, 사용자별 SSH 세션과 공유 로컬 전달은 매우 다른 기록을 남기기 때문이다.

마지막으로, 조직 자체의 게이트 없이는 노트북에서 대상 네트워크에 전혀 도달할 수 없어야 한다면 VPN을 골라라. 개인 전달은 설계상 그 게이트를 우회하므로, 그것은 셸 기록이 아니라 변경 기록에 남아야 한다.

전달이 크게 실패하게 하라

바인딩이 실패하면 연결된 것처럼 보이지만 아무것도 전달하지 않는 셸을 남기지 않고 세션이 멈추도록 ExitOnForwardFailure=yes를 써라. 호스트 키 검증은 켜 두고, 비밀번호보다 키나 에이전트를 선호하라. 그런 다음 뷰어가 쓸 정확한 URL을 시험하라, 동작하는 SSH 세션과 동작하는 화면 연결은 서로 다른 결과이기 때문이다.

macOS의 네이티브 클라이언트에서는 로컬 URL open "vnc://127.0.0.1:15900" 로 뷰어에 도달한다. 창이 열리는데 원격 호스트가 인증을 거부하면 터널은 정상이고 문제는 대상에 있다. 창이 전혀 열리지 않으면 문제는 리스너나 포트에 있다.

끝나면 세션을 멈추고, 포트, 배스천, 대상, 계정 정책을 적어 두어라. 아무도 문서화하지 않은 전달은 여섯 달 뒤 백도어와 구별되지 않으며, 그래서 작고 이름이 있고 일시적으로 유지해야 한다는 것이 가장 강한 근거다.