참조 : http://blog.naver.com/PostView.nhn?blogId=alice_k106&logNo=221364560794&parentCategoryNo=&categoryNo=22&viewDate=&isShowPopularPosts=false&from=postView

1. SSH 포트 포워딩이란?

많은 개발자들이 SSH를 단순히 원격 터미널 접속 용도로만 사용한다. 그렇지만 SSH는 기본적인 접속 기능 외에도 'SSH 포트 포워딩' 또는 'SSH 터널링 기능' 이라고 불리는 것을 제공한다 (두 용어는 같은 것을 의미한다). 터널링이라는 단어는 보통 VXLAN의 Overlay Network에서 물리적 토폴로지를 논리적으로 나눌 때에나 등장하는 단어일 터인데, 신기하게도 SSH 에서도 그와 비슷한 기능을 사용할 수 있다. 

단적으로 말하자면, SSH 터널링은 '프록시' 와 비슷한 역할을 하며, SSH의 특징 상 SSH 터널링을 통해 전달되는 데이터는 모두 암호화된다. 그렇다면 SSH 터널링은 무엇을 위한 프록시인가, 를 짚고 넘어가야 할 것 같다

SSH 포트 포워딩을 사용할 수 있는 단적인 예를 들어 보자. 나는 A 서버에서 80 포트로 바인딩 된 서비스에 접근할 필요가 있다. 그러나 보안 상의 이유로 A 서버의 Firewall에서 SSH (22 포트) 외의 포트는 전부 차단된 상태이다. 당연히 Firewall은 80 포트를 개방하지 않았기 때문에 해당 서비스로 접근이 불가능하다. 

이 때, SSH 포트포워딩을 사용하면 SSH 터널링을 통해 웹 서버에 접근할 수 있다. 80 포트를 사용하는 서비스와 SSH 서버를 엮은 뒤 SSH 터널링을 생성하고, 사용자가 서비스를 요청하면 해당 요청은 SSH 서버로 전송된 뒤 A 서버 내부에서 다시 포워딩된다.

일단 사용자와 서버 간의 SSH 터널링이 수립되고 나면 데이터의 요청 및 반환은 모두 SSH 서버를 통해 일어나므로 서버의 80 포트로 접근할 필요가 없다. 따라서 SSH 서버는 터널링을 통해 데이터를 주고받을 수 있게 해주는 일종의 프록시의 역할을 수행하게 된다. 

.... 설명은 이렇게 했지만 SSH 터널이라는 개념 자체는 원래 SSH 연결에서 사용되는 것이며, SSH 클라이언트와 SSH 서버 사이의 연결 통로 자체를 SSH 터널이라고 부른다. 즉, SSH 연결 수립 뒤 외부로부터 데이터를 보호할 수 있는 일종의 연결 통로를 터널이라고 부른다고 한다. SSH 터널링은 Secure Shell 상의 데이터뿐만 아니라 기타 애플리케이션의 데이터 또한 SSH 터널을 이용하게 함으로써 암호화 등과 같은 SSH의 장점을 활용할 수 있는 방법이라고 보면 된다. [4]

그러나 잘만 악용하면 나쁜 의도로 사용할 수도 있기 때문에 공격자의 관점에서 SSH 포트 포워딩을 바라볼 필요도 있을 것이다. 보안 측면에서도 SSH 터널링을 생각해 볼 필요가 있다는 이야기이다.

2. SSH 포트 포워딩 사용하기

SSH 포트 포워딩에는 크게 2가지 종류가 있다. Local, Remote 모드를 사용할 수 있고, Dynamic이라는 것도 있는 듯 하지만 지금은 다루지 않기로 했다.

2.1 서버 구성

당연하겠지만, SSH를 기반으로 하기 때문에 SSH Client와 SSH Server로 사용할 서버 각각 1대가 필요하다. VM을 사용해 아래와 같이 구성하였다. 

테스트를 위해 SSH 서버에서는 Nginx 웹 서버를 80 포트와 바인딩해 컨테이너로 생성해 놓았다. SSH 포트 포워딩을 통해 SSH Client에서 해당 Nginx 웹 서버로 접근할 것이다.

2.2. Local 포트 포워딩

SSH 포트 포워딩은 연결을 수립하는 주체가 누구냐에 따라 Local과 Remote로 구분할 수 있다. Local은 가장 이해하기 쉽고 직관적인 경우로, 늘 하던 것처럼 SSH Client -> SSH Server로 연결을 수립하는 경우이다. 이해를 위해 간단한 예시를 통해 Local 포트 포워딩을 사용해보자.

SSH Client는 SSH Server에 SSH로 접속할 수 있다. 그러나 Nginx 서버는 127.0.0.1:80으로 바인딩되어 있어 외부에서 접근할 수 없는 상황이다. SSH Client 에서 Nginx에 접근할 수 있도록 SSH 터널링 연결을 생성한다.

가장 많이 헷갈리는 것이 SSH 포트 포워딩 시 '무엇을 어떻게 입력할지' 인데, 위 그림으로 이해할 수 있다. SSH Client에서 ssh -L [로컬에서 사용할 포트]:[최종적으로 접근할 곳] [SSH Server 주소] 형식으로 입력한다. SSH 터널이 생성된 뒤에는 [로컬에서 사용할 포트] 를 이용해 [최종적으로 접근할 곳] 에 접근할 수 있다.

직접 해보자. 가장 먼저, SSH Server 에서는 Nginx 서버시 127.0.0.1:80 으로 바인딩되어 실행되고 있다.

SSH Client에서 아래의 명령어를 입력해 SSH 포트 포워딩을 실행한다. SSH Server의 주소는 192.168.1.201 이고, 해당 SSH Server에서 접근할 Endpoint는 127.0.0.1:80 (Nginx Server) 이며, SSH Client의 8585 포트로 해당 Endpoint에 접근할 것이다.

평상시와 똑같이 SSH 접속에 성공하였지만, SSH 터널이 생성된 상태이다. SSH Client에서 새로운 터미널을 생성한 뒤, 로컬호스트의 8585로 요청을 전송해보자.

요청이 제대로 전송되었고 응답 또한 수신하였다. SSH 터널링은 수립된 SSH 연결을 통해 구성되기 때문에 위에서 접속한 SSH 연결을 끊으면 SSH 터널 또한 종료된다.

2.3 Remote 포트 포워딩

Remote 포트 포워딩은 SSH Server -> SSH Client 로 연결을 수립해 SSH 터널을 생성한다. 연결을 생성하는 주체가 SSH Server이기 때문에 SSH Server의 22 포트를 Firewall에서 개방해 둘 필요가 없다. 이는 역으로 말하자면 22 포트를 포함해 모든 포트가 Firewall에 의해 막혀 있는 상태이더라도, SSH 터널을 생성해 SSH Server에서 실행 중인 서비스, 또는 SSH Server가 접근 가능한 네트워크에 접속할 수 있다는 의미가 된다.

간단한 예시를 들어보자. 외부로 나가는 트래픽은 허용되지만 내부로 들어오는 트래픽은 Firewall에 의해 전부 차단되는 상황을 가정한다. 물론 SSH 또한 사용할 수 없는 상황이다.

이 때 Remote 포트 포워딩을 SSH Server에서 사용한다면 내부 네트워크에 쉽게 접속할 수 있다. Outbound 트래픽은 허용되는 상황이므로 SSH Server -> SSH Client로 SSH 터널(SSH 연결)을 생성한 뒤, SSH Client는 SSH Server가 접근 가능한 네트워크에 접속해 데이터를 주고 받는 방식이다.

어찌 보면 보안상으로 취약하다고 말할 수 있다. Firewall 단에서 모든 포트로 들어오는 Inbound 트래픽을 차단해도 Outbound 트래픽을 통해 내부 네트워크에 자유롭게 접근할 수 있기 때문이다. 따라서 SSH 연결이라고 해서 무조건 Trust한 패킷만 오고 간다고 볼 수는 없다. 

어쨌든, 사용해보는 것이 가장 빠르게 이해할 수 있는 지름길이다.

이번에는 SSH Server 에서 ssh -R [SSH Client가 사용할 포트]:[최종 목적지] [SSH Client 주소] 와 같은 형식으로 SSH 포트 포워딩을 실행한다. 당연하지만, SSH Client에서도 SSH 데몬이 실행 중이여야만 한다. SSH Server에서 SSH Client로 SSH 연결을 수립하기 때문이다.

SSH Client 측에서 로컬 호스트의 8585로 접근하면 127.0.0.1:80에 접근할 수 있다.

3. 장단점?

SSH를 기반으로 하다 보니 보안, 데이터 압축, 암호화 등은 알아서 해줄 뿐만 아니라 간단하게 데이터를 주고 받을때는 편리하게 프록시 대신 사용할 수 있다는 장점이 있다. 그러나 대용량 데이터를 주고 받을때는 속도가 느려질 수 있다는 단점이 있다. 아래와 같이 iperf로 간단히 측정해보니 전송 속도가 약 두 배 정도 차이가 났다. (설마 이걸로 뭔가 대용량 데이터를 처리하는 사람은 없겠지...) 또한 TCP만 지원한다는 한계점도 있다.

IPSec이나 사내 내부망이 보안 기능을 제공하고 있다면 그러한 것을 선택하는 것도 하나의 대안이 될 수 있겠다. 요즘은 네트워크 속도 잘나오는 VXLAN, IPSec도 많다고 들었으니 말이다.

참고 자료

[1] 그림 매우 매우 잘그려 놨음. 이 글을 봤는데도 이해가 안된다면 가서 읽어볼것 : 

https://unix.stackexchange.com/questions/115897/whats-ssh-port-forwarding-and-whats-the-difference-between-ssh-local-and-remot

[2] 간단한 설명 : http://itsaessak.tistory.com/171

[3] 간단한 설명 : http://linux.systemv.pe.kr/ssh-%ED%8F%AC%ED%8A%B8-%ED%8F%AC%EC%9B%8C%EB%94%A9/

[4] 이해하기 좋은 설명 : https://swalloow.github.io/ssh-tunneling

[5] 매우매우 자세한 설명. 더 궁금하면 읽어볼것. 

http://www.hanbit.co.kr/network/category/category_view.html?cms_code=CMS5064906327

참고 ) http://docs.likejazz.com/apache-nginx-perf-comparison/

Apache와 Nginx의 PHP 성능 비교

21 Dec 2015

이벤트 방식인 Nginx 는 프로세스/쓰레드 방식인 Apache 에 비해 월등한 성능을 보이는 것으로 알려져 있다. 실제로 Static 파일들 CS, JSS 의 경우엔 두드러져 보이는데, 그렇다면 CGI 도 이에 해당되는지 특히 PHP 의 경우를 예로 들어 살펴본다.

• 서론
• 테스트
  • 성능
• 전통적인 CGI
• 결론

서론

PHP 를 웹으로 서빙하는 케이스는 크게 3 종류로 나눌 수 있다.

1. PHP Built-in 웹 서버
2. Apache w/ mod_php
3. Nginx w/ FastCGI

1번의 경우 개발시에 웹 서버를 별도로 셋팅하기 번거로울 경우 쉽게 사용할 수 있는 방법이고, 실제로 흔히 사용한다. 그러나 편의상 사용되며 성능과는 거리가 멀다. 따라서 여기서는 더 이상 언급하지 않기로 한다.

2번의 경우 10 여년 이상 사용해온 전통적인 방식이며 LAMP 스택(Linux, Apache, MySQL, PHP)이란 이름으로 지금의 아파치와 PHP 를 있게 한 장본인이다.

3번의 경우 PHP-FPM 과 함께 최근에 주로 쓰이는 방식인데, FPM 은 FastCGI Process Manager 의 약자이며 PHP-FPM 은 PHP FastCGI 의 대안 구현으로 2010년 PHP 코어에 팩키징되고 2011년 실험적인(experiment) 딱지를 뗌으로써 사실상 PHP FastCGI 표준 구현으로 자리 잡았다. 특히 아파치에 비해 월등한 성능을 보이는 Nginx 와 손쉽게 연동되며 최근 LEMP 스택(Linux, Nginx, PHP, MySQL/MariaDB)이란 이름으로 새로운 트렌드를 주도하고 있다.

그렇다면 3번 구현은 과연 새로운 트렌드로써 월등한 성능을 보여주고 있는지 직접 확인해보도록 한다.

테스트

테스트 서버의 사양은 아래와 같다.

• Intel Xeon E312xx (Sandy Bridge) x 2
• 4G RAM
• OS: Ubuntu 14.04
• Apache, Nginx 모두 apt 를 이용한 기본 설치, 설정 변경 없음

요즘 기준으로 보면 웹 서버로 쓸 수 있는 거의 최소 사양인데 테스트 PHP 코드가 과연 얼만큼의 성능을 보여주는지 확인해본다.

성능

코드는 간단한 HTML 을 변수에 삽입한 다음 템플릿을 구성해서 내려주는 형태이며, 별도의 외부 서버나 DB 호출은 하지 않는다.

carrotw 는 사내에서 만든 브라우저로 직접 부하 테스트가 가능한 성능 테스트 도구(외부에 공개되지 않은 사내 시스템이라 부득이하게 주소를 가림)다. 전통적인 쓰레드 방식으로 동작하며 여기서는 쓰레드를 200개 주어 최대 성능을 측정했다. 200개 쓰레드가 동시에 요청을 보내 응답을 받아오는 초당 평균 횟수/속도를 측정하는 방식이며 10초간 측정한 결과는 약 7,600 TPS 에, 평균 응답속도 25ms 수준이다.

아주 좋은 성능의 서버가 아님에도 불구하고 초당 7,600회 처리라는 준수한 성능을 보여준다. 그렇다면 과연 아파치는 Nginx 에 비해 어느 정도 성능이 나오는지 확인해본다.

동일한 200개 쓰레드에서 7,100 TPS, 27ms 가 나왔다. 이를 표로 정리하면 아래와 같다.

방식TPS응답 속도

단순 TPS 만 비교하면 Nginx 가 아파치 보다 약 7% 정도 성능이 더 좋은것으로 나온다. CSS, JS 등의 Static 파일이 압도적인 성능을 보여주는 것에 비하면 성능이 약간 높긴 하나 다소 실망스런 결과다.

Why is FastCGI /w Nginx so much faster than Apache /w mod_php? 를 보면 비슷한 얘기를 하고 있다. 아파치 설정을 튜닝하고 불필요한 시스템 콜을 없애자 실제로는 비슷한 성능을 보여주며 큰 파일(100KB)인 경우 오히려 아파치가 더 나은 성능을 보여준다고 한다.

전통적인 CGI

따라서 CGI(PHP) 용도로 아파치나 Nginx 나 별 차이가 없다는 결론에 이른다. 그러나 전통적인 CGI(Traditional CGI) 방식과는 압도적인 성능 차이가 있음에 유의해야 한다. 아래는 여러가지 언어로 전통적인 CGI 를 구현하고 아파치 cgi-bin 에서 구동한 결과다.

방식TPS코드

예상했듯이 C 가 가장 빠르고 그 다음 C++ > Bash > PHP > Python 순이다. 전통적인 CGI 방식은 프로세스를 직접 실행한 결과를 보여주는 방식이기 때문에 미리 바이너리를 만들고 사이즈가 가장 작은 C 가 가장 빠르다.

그러나 이 역시도 mod_php 에 비하면 1/7 수준에 불과하다. 따라서 특수한 경우를 제외하곤 굳이 C 로 전통적인 CGI 를 만들어야 할 이유가 전혀 없다. 재밌는 점은 PHP 의 경우인데, 전통적인 CGI 에서는 250 TPS 밖에 나오지 않지만 mod_php/FastCGI 에서 돌리면 7,100 ~ 7,600 TPS 가 나온다. 거의 30배 이상 성능 차이가 난다.

결론

Static 파일과 달리 CGI(PHP) 방식에서 Apache w/ mod_php 와 Nginx w/ FastCGI 의 성능 차이는 크지 않다. 따라서 각자에게 편한 웹 서버를 사용해도 무방하다. 그러나 전통적인 CGI 방식과는 성능 차이가 매우 크므로 특수한 경우를 제외하곤 전통적인 CGI 방식은 사용하지 않는게 좋다.

참고자료 : https://velopert.com/3612