SSH 터널은 열렸는데 브라우저가 안 된 이유와 원격 관리 경로 정리

집에서도 ESXi와 vCenter, 자동화 서버를 관리하고 싶었다. 내부망에 있는 NFS 서버가 Tailscale에 연결돼 있어 이 서버를 원격 진입 지점으로 사용했다. 관리 대상마다 인터넷에 포트를 여는 대신 이 서버를 거쳐 내부로 접근하는 흐름을 잡았다.

처음에는 SSH 동적 포워딩으로 SOCKS5 터널을 열었다. 터미널은 정상적으로 대기했지만 Chrome에서 내부 관리 주소를 열자 화면이 나오지 않았다. 터널이 열렸다는 결과와 브라우저가 그 터널을 사용한다는 결과가 달랐다.

터널만 열고 Chrome에는 프록시를 지정하지 않았다

첫 연결에서는 로컬 loopback의 1080 포트를 SOCKS 진입점으로 사용했다. SSH 세션은 명령을 실행하고 끝나는 대신 연결을 유지하는 상태였다. 그런데 평소 사용하던 Chrome에서 내부 주소를 열었고 다음 오류가 나왔다.

페이지가 작동하지 않습니다.
ERR_EMPTY_RESPONSE

이때 Chrome에는 SOCKS 프록시 설정이 없었다. SSH로 프록시 통로를 만들어도 다른 프로그램이 자동으로 그 통로를 이용하는 것은 아니었다. 브라우저가 내부망으로 직접 접근하려는 상태와 SOCKS를 거치는 상태를 구분해야 했다.

별도 Chrome 프로필을 사용하고 프록시 주소를 socks5://127.0.0.1:1080으로 지정해 실행한 뒤 접속에 성공했다. 평소 브라우저 설정 전체를 바꾸기보다 관리 작업에 사용할 프로필을 분리한 방식이었다.

웹 접근과 SSH 관리를 다른 경로로 정리했다

브라우저로 여러 내부 관리 UI를 볼 때는 SOCKS가 편했다. 반면 자동화 서버나 CI 서버, Kubernetes Control Plane에 SSH로 들어갈 때는 Jump Host를 지정하는 방식으로 정리했다. 로컬 PC에서 Tailscale 진입 서버를 거쳐 내부 관리 대상에 연결하는 흐름이다.

두 방식 모두 같은 진입 서버를 사용했지만 목적은 달랐다. SOCKS는 해당 프록시를 쓰도록 설정한 프로그램의 요청을 전달했고, ProxyJump는 내부 SSH 대상에 연결할 때 중간 호스트를 지정했다. 브라우저가 동작한다고 SSH 대상 계정이나 키 인증까지 확인된 것은 아니므로 각 대상의 접속을 따로 봤다.

이렇게 정리하니 오류가 났을 때도 확인 순서를 나눌 수 있었다. 진입 서버까지 연결되는지, 내부 대상에 접근 가능한지, 애플리케이션이 올바른 프록시나 전달 포트를 쓰는지에 따라 조사할 곳이 달랐다.

localhost 서비스는 Local Forward로 전달했다

Jenkins는 자동화 서버의 loopback에서 서비스했다. 이 관리 화면을 집에서 볼 때는 Jump Host를 거친 SSH 연결에 Local Forward를 사용했다. 집 PC의 로컬 포트를 원격 서버의 127.0.0.1:8080으로 연결하고 브라우저도 집 PC의 loopback 주소로 열었다.

초기 예시에서는 로컬 18080을, 최종 작업에서는 18081을 사용했다. 집 PC에서 선택한 전달 포트가 달라진 것이지 Jenkins 서비스 자체의 포트가 바뀐 것은 아니었다. 로컬 포트, 원격 도착지, 브라우저 주소를 한 줄의 숫자로 섞지 않고 각각 구분했다.

후속 Argo CD 관리에는 SSH Local Forward와 Kubernetes port-forward를 함께 사용했다. 로컬 브라우저에서 SSH 터널을 지나 Control Plane의 loopback으로 가고, 그곳의 port-forward가 Argo Service에 연결하는 구조였다. 전달 단계가 두 개인 만큼 작업을 마칠 때도 로컬 SSH 연결과 원격 port-forward를 확인했다.

연결 성공과 TLS 신뢰도 따로 확인했다

초기 관리 UI 연결을 진단할 때는 자체서명 인증서 문제를 분리하기 위한 예시도 사용했다. 하지만 네트워크 통로가 생기는 것과 대상 인증서를 신뢰하는 것은 다른 문제였다. 후속 Registry와 RCA 서비스에서는 사설 CA와 대상 이름을 검증하는 절차를 별도로 두었다.

이 원격 관리 구성이 PC 전체의 DNS나 hosts, 전역 CA 신뢰까지 설정한 것은 아니다. 특정 관리 경로로 접속에 성공한 범위에서 결과를 기록했다. Tailscale subnet router도 대안으로 검토했지만, 실제 사용한 흐름은 SOCKS와 SSH 터널을 중심으로 정리했다.

작업을 끝낼 때는 연결을 여는 것만큼 닫는 과정도 남겼다. 최종 배포 검증에서는 작업용 로컬 터널과 원격 port-forward의 종료를 확인했다. 다음에 관리할 때도 어느 터미널이 어느 전달 경로를 유지하는지 알 수 있도록, 접속 목적과 종료 대상을 함께 적어두려 한다.