SSH Tunnel - Reverse Proxy Server 만들어보기(방화벽 우회)

오픈소스로 개발을 해보려고 하는데 컨셉 정리부터 해보려고 글을 작성한다.

 

일단 IoT 장치들 같은 경우에는 위대한 방화벽 뒤에 설치가 되고,

그 방화벽 설정은 내가 변경할 수 없는 경우가 많다.

 

실제로 회사 다니면서 이에 대한 문제로 1~2주간 머리를 싸맨 적이 있는데,

그때 내가 이용한 것이 SSH Reverse Tunneling이었다.

 

당시 개념 이해에 도움을 받은 글

https://unix.stackexchange.com/questions/46235/how-does-reverse-ssh-tunneling-work

How does reverse SSH tunneling work?

 

나의 상황

 

 

이런 식인 것인데,

간단하게 말하면

 

방화벽 뒤에 있는 친구가 있고, 나는 그에 액세스 하고 싶다.

그런데

 - 방화벽 설정을 건들 수 없다.

 - 퍼블릭 IP가 뭔 줄 알고?

 

인 상황을 타개하게 해 준 것이 SSH Tunneling이다.

 

이게 작동하는 구조를 보면

1. 방화벽 뒤에 있는 장치가 Public Server에 접속해서 Remote Proxy 포트를 하나 만든다.

2. 유저는 Public Server에 SSH 한다

3. Public Server 내부에 있는 장치가 만든 Remote Proxy 포트에 또 SSH를 한다

 

SSH inside SSH를 해서 방화벽을 우회한다. 는 컨셉이다.

 

처음에 개발할 때는 워낙 급한 기능이어서 상시로 연결돼있게 만들었고, 접속 체크도 좀 원시적으로 되어있었다.

대에충 이런식..

접속 체크는 lsof를 사용해서 폴링으로 체크를 했었고 Provisiong도 손으로..

(생각해보니까 python thread 띄우고 subprocess sync로 돌리다 죽으면 끊겼다고 체크도 가능했을 것 같기도..? ㅁ?ㄹ)

 

 

근데, 이렇게 하면 추후 확장성에 문제가 생기고, 사용 안 하는 장치들도 포트를 계속 점유하게 된다.

또한 세션이 계속 유지되니까 성능을 잡아먹는다는 문제도 발생한다.

 

해서 개선을 한다고 하면 아래와 같이 할것 같은데 AWS로 넘어갈건데 굳이..? 라는 생각도 들고..

 

MQTT / Websocket을 사용해서 on-demand port allocation

1. 장치에서 도는 데몬은 MQTT 혹은 Websocket을 통해서 서버와 heartbeat만 주고받다가

2. 유저가 웹 인터페이를 통해서 이 장치 연결 좀 해줘 하면

3. 서버는 장치한테 MQTT publish를 하고

4. 장치는 그 메시지를 받으면 터널을 개시한다.

5. 그리고 서버는 터널이 할당된 포트에 Proxy 해주는 url을 만들어서 유저가 간단하게 접속할 수 있는 환경을 만들어준다.

 

이렇게 설계가 되면 나중에 좋은 것이, 장치를 그룹별로 모아둔 뒤에 특정 shell script 실행시켜! 이런 기능도 추가해서

업데이트 대응이나 이런 것도 가능할 수 있을 것 같다.(AWS IoT 에서도 있는..)

 

나중에 각 잡히면 해볼 계획이다.

 

생각해봐야 할 것.

1. 해당 서버 확장에 대한 대책

2. 자동 프로비저닝 방안

3. URL 생성 관련 방법(이거는 뭐 DNS 서버 이런 거 쓰는 건가? - 공부 필요)

4. 보안

 

재미있을 것 같다.