프록시란?프록시(Proxy)란 '대리'라는 의미로,네트워크 기술에서는 프로토콜에 있어서 대리 응답 등에서 친숙한 개념입니다. 보안 분야에서는 주로 보안상의 이유로 직접 통신할 수 없는 두 점 사이에서 통신을 할 경우 그 상이에 있어서 중계기로서 대리로 통신을 수행하는 기능을 가리켜 '프록시', 그 중계 기능을 하는 것을 프록시 서버라고 부릅니다.
프록시 서버의 특징프록시 서버는 클라이언트 입장과 서버의 입장에서 볼 때 서로 상반되는 역할을 하는 것처럼 인식됩니다. 다시 말해서, 클라이언트 호스트에서의 입장에서 본다면 프록시 서버는 마치 원격 서버처럼 동작하는 것이고, 원격 서버에서의 입장에서 본다면 마치 클라이언트처럼 동작한다는 것입니다. 프록시 서버는 단순히 보안상의 이유만으로 설치하는 것은 아닙니다. 물론 보안상의 목적으로 설치하는 경우가 많겠지만, 그렇다고 그렇게 단순하게 볼 수만은 없을 것입니다. 우선 프록시 서버는 프록시 서버에 요청된 내용들을 캐시를 이용하여 저장해 둡니다. 이렇게 캐시를 해 두고 난 후에, 캐시 안에 있는 정보를 요구하는 요청에 대해서는 원격 서버에 접속하여 데이터를 가져올 필요가 없게 됨으로써 전송 시간을 절약할 수 있게 됨과 동시에 불필요하게 외부와의 연결을 하지 않아도 된다는 장점을 갖게 됩니다. 또한 외부와의 트래픽을 줄이게 됨으로써 네트워크 병목 현상을 방지하는 효과도 얻을 수 있게 됩니다. 프록시 서버의 종류서버의 위치에 따라 분류하면 크게 두 가지로 나눌 수 있습니다. Forward 프록시이것은 프록시 서버를 '클라이언트 호스트들과 접근하고자 하는 원격 리소스의 사이'에 위치시키는 것입니다.이 프록시 서버는 원격 서버로부터 요청된 리소스를 가져와서 요청한 사용자에게 돌려주는 역할을 수행하며, 만일 캐시에 데이터가 남아 있다면 다음 요청시 캐시된 데이터로부터 제공해 주게 됩니다. 이 서버는 전형적으로 로컬 디스크에 데이터를 저장하며, 클라이언트 호스트들은 사용중인 웹 브라우저를 이용하여 프록시 서버 사용 설정을 해야 하므로 프록시 서버를 사용하고 있다는 것을 인식할 수 있을 것입니다. 이 방식은 대역폭 사용을 감소시킬 수 있다는 것과 접근 정책 구현에 있어 다루기 쉬우면서도 비용이 저렴하다는 장점을 갖습니다. 또한 사용자의 정해진 사이트만 연결할수 있는 등 웹 사용 환경을 제한할 수 있으므로 기업 환경등에서 많이 사용합니다. Reverse 프록시이것은 프록시 서버를 '인터넷 리소스 또는 인트라넷 리소스 앞'에 위치시키는 방식입니다. 이 방식을 사용하면 클라이언트들이 프록시 서버에 연결되었다는 것을 알지 못하게 되며, 마치 최종 사용자가 요청 리소스에 직접 접근하는 것과 같이 느끼게 됩니다. 내부 서버가 직접 서비스를 제공해도 되지만 이렇게 구성하는 이유는 보안 때문입니다. 보통 기업의 네트워크 환경은 DMZ 라고 하는 내부 네트워크와 외부 네트워크 사이에 위치하는 구간이 존재하며 이 구간에는 메일 서버, 웹 서버, FTP 서버등 외부 서비스를 제공하는 서버가 위치하게 됩니다. example.com 사는 서비스를 자바로 구현해서 WAS 를 DMZ 에 놓고 서비스해도 되지만 WAS 는 보통 DB 서버와 연결되므로 WAS 가 최전방에 있으면 WAS 가 털릴 경우 DB 서버까지 같이 털리는 심각한 문제가 발생할 수 있습니다. 이 때문에 리버스 프록시 서버를 두고 실제 서비스 서버는 내부망에 위치시키고 프록시 서버만 내부에 있는 서비스 서버와 통신해서 결과를 클라이언트에게 제공하는 방식으로 서비스를 하게 됩니다. 특히 리눅스 환경에서 리버스 프록시로 아파치 웹 서버를 사용한다면 SELinux 를 켜 놓으면 SELinux 의 기본 정책이 웹 서버는 톰캣의 8080, 8009 포트만 접근 할 수 있으므로 아파치 웹 서버가 해킹당해도 웹 서버 권한으로는 내부망으로 연결이 불가합니다. 또한 리버스 프록시 방식은 각 요청에 대한 데이터가 캐시되기 때문에 프록시 서버는 실제 서버들을 위한 부하조절 기능을 가질 수 있습니다.
이번 포스팅에서는 HTTP 완벽가이드 책을 활용하였습니다. 5장 web server는 github의 구현코드를 확인 바랍니다. 추가적으로 Connection 관리 학습을 하며 TCP 밑단 프로토콜 학습을 위한 코드도 작성하였으니 테스트 코드를 돌려보시거나, 직접 코드 수정 후 wireshark로 확인하실 수 있습니다. 1. Proxy란? 같은 프로토콜을 사용하는 둘 이상의 애플리케이션을 연결하는 용도로 사용된다. (HTTP version 변환은 가능하며, 상용 Proxy Server는 SSL, 방화벽, FTP 접근 등 웹 기반 애플리케이션을 지원하기 위해 Gateway 기능이 구현되어 있다.) * 서로 다른 프로토콜을 사용하는 둘 이상을 연결하기 위해서는 Gateway를 사용한다. 2. Proxy Server가 사용되는 예 성인컨텐츠 등을 차단하는 어린이 필터, 보안등급이 있는 문서에 대한 접근 제어, 보안 방화벽, 웹 캐시, Reverse Proxy, Contents Router, TransCoder, Anonymizer 등으로 사용된다. 이 중 Contents Router란 인터넷 트래픽 조건과 컨텐츠 종류에 따라 요청을 특정 웹 서버로 유도하는 역할을 한다. Anycast와 비교해서 확인해보는 것도 좋겠다. Transcoder란, 컨텐츠를 클라이언트에게 전달하기 전에 본문 포맷을 수정(GIF -> JPG, image resize, 압축, 언어 변환)하는 것을 말한다. apache의 mod_deflate, mod_ssl 등의 모듈 등을 활용하여 같은 효과를 낼 수 있다. 그리고 Anonymizer는 개인 식별 정보를 제거하여 익명성 보장에 기여한다. 구체적으로, User-Agent 헤더에서 사용자의 컴퓨터와 OS 종류 제거, 어떤 사이트를 거쳐서 방문했는지 알기 어렵게 하기 위해 Referer 헤더 제거, 프로필과 신원 정보를 없애기 위해 Cookie 헤더 제거 등이 있다. 3. Proxy Server의 종류 1) Egress Proxy: LAN 구간과 Internet 구간에서 방화벽, 인터넷 트래픽 성능 개선 등의 역할을 한다. (어린이 필터 등이 여기에 위치한다.) 2) Ingress Proxy: LoadBalancer 역할을 한다. Kubernetes의 ingress의 기능을 같이 확인해보는 것도 좋겠다. [Nginx Ingress에서 Proxy Protocol을 통해 Client Source IP를 가져오는 방법] 3) Reverse Proxy: 웹서버로 향하는 모든 요청을 처리하고 필요할 때만 웹 서버에게 자원을 요청할 수 있다. 또한 웹 서버에 보안 기능을 추가하거나 빠른 웹 서버 캐시를 느린 웹 서버의 앞에 놓음으로서 성능을 개선할 수도 있다. Reverse Proxy는 일반적으로 웹서버의 이름과 IP 주소를 자신으로 가징하기 때문에, 모든 요청은 서버가 아닌 이 Proxy로 가게 된다. 4. Proxy Server의 요청 처리방식 Proxy Server들은 origin server에 가까운 Proxy Server를 parent로 둔다. 일반적으로 자신의 parent proxy 혹은 origin server에게 라우팅하는데, contents router, reverse proxy 등의 경우처럼 동적으로 parent를 선정하는 경우가 있다. 이 경우 현재 부모들의 작업량 수준에 근거하여 선택(Load Balancing), 지리적 인접성에 근거하여 선택, 특정 URI의 요청을 처리하는 프락시 서버를 선택, 유료 서비스 가입자를 위한 라우팅 등의 방법이 있다. 그렇다면 Proxy Server는 트래픽을 어떻게 처리할까? 웹 브라우저에서 Proxy를 사용하도록 설정하여 의도적으로 origin server가 아닌 Proxy로 보낼 수 있다. 그리고 트래픽을 가로채어 Proxy로 리다이렉트하는 방식(Transparent Proxy)과 웹 서버에서 HTTP Redirect 명령을 클라이언트에게 돌려줌으로써 클라이언트의 요청을 Proxy로 리다이렉트할 수있다. 그 외에 Reverse Proxy는 웹서버의 이름과 IP주소를 자신이 직접 사용하여 모든 요청을 서버 대신 자신이 받는다. 5. Proxy 요청의 미묘한 특징들 * 클라이언트가 Proxy 대신 서버로 요청할 경우 완전한 URI를 갖는다. Proxy는 목적지 서버와 커넥션을 맺어야 하기 때문에, 그 서버의 이름, URI 스킴을 알 필요가 있다. VirtualHost는 부분 URI로 인해 발생하는 문제를 호스트와 포트에 대한 정보가 담겨있는 Host 헤더를 통해 해결한다. Proxy도 부분 URI이고 Host 헤더가 있다면 이를 통해 정보를 알아내야 한다. 만약, Transparent Proxy와 같은 방식으로 동작할 경우엔 Client는 Proxy가 있음을 알지 못함으로 부분 URI를 보낼 수 있고, 브라우저에서 Host 헤더를 지원하지 않을 경우라면 어떻게 해야할까? - Reverse proxy라면
Proxy에 실제 서버의 주소와 포트번호가 설정되어 있을 수 있다
* Proxy가 없는 경우엔 기본스킴으로 'http://' 기본포트로 80 기본 경로를 '/'로 간주한다. 실패할 경우, DNS resolve 를 활용하여 도메인을 검색한다. 웹 브라우저는 Proxy에 요청할 경우 부분 호스트명을 자동확장하지 않는다.  만약 Transparent Proxy가 있을 경우, 브라우저는 Proxy가 있는지 알 수 없으므로 자동확장하고, DNS resolve를 활용하여 요청한다. 만약 DNS에 등록된 서버가 죽은 서버일 경우(DNS는 서버의 health를 보장해주지 않는다. DNS 다중화의 문제점에 대해 링크에서 확인할 수 있다.) Proxy Server가 다른 IP 주소로 인계하여야 한다. 6. 메시지 추적 * 보안과 비용 절감을 위해 인터넷 접속시 Cache Proxy Server를 사용하며, 많은 대형 ISP들이 성능 개선과 기능 구현을 위해 Proxy Cache를 사용한다. 동시에 성능상의 이유로 세계 곳곳에 흩어져 있는 대리 Cache 저장고에 Contents를 복제해두는 방식이 점점 더 흔해지고 있다. * Proxy가 점점 더 흔해지면서, 서로 다른 스위치나 라우터를 넘나드는 IP 패킷의 흐름을 추적하는 것 못지 않게 Proxy를 넘나드는 메시지의 흐름을 추적하고 문제점을 찾아내는 것도 필요한 일이 되었다. Via 헤더 필드는 메시지가 지나는 각 중간 노드(Proxy나 Gateway)의 정보를 나열한다. (Via: 1.1 proxy-62.irenes-isp.net, 1.0 cache.joes-hardware.com) Via 헤더 필드는 메시지의 전달을 추적하고, 메시지 루프를 진단하고, 요청을 보내고 그에 대한 응답을 돌려주는 과정에 관여하는 모든 메시지 발송자들의 프로토콜을 다루는 능력을 알아보기 위해 사용된다. * Proxy는 이해할 수 없는 헤더 필드는 반드시 그대로 전달해야 하며, 같은 이름의 헤더 필드가 여러 개 있는 경우에는 그들의 상대적인 순서도 반드시 유지해야 한다. 7. 그 외 Proxy 관련 주제들.. 1) Ngrok 패킷 분석 * 로컬(192.168.7.144)에서 서버를 띄우고 브라우저로 확인해서 헷갈릴수도 있겠다. 1. ngrok을 실행하니, 우선 3.15.53.92의 원격 서버의 주소를 알아온 후 SSL Tunneling을 맺는다. 2. 자동으로 생성한 주소(b2612480.ngrok.io를 DNS Server의 CNAME으로 매핑하는 듯 하다. 매번 주소가 바뀐다. (AWS EC2일 때도 있고, akamai 장비일 때도 있다.) 3. b2612480.ngrok.io의 IP를 알아온 후 해당 브라우저로 요청 시 서버에서 SSL 터널링으로 데이터를 보내는 것을 확인할 수 있다. 이것으로 18.188.14.65 proxy 서버와 3.15.53.92 서버간에 Port forwarding 되어 있을거라 추측해본다.
* 잘 정리된 포스팅이 있어서 링크를 남겨둔다. 3) Ingress with Kubenetes |
HTTP Proxy 란 - HTTP Proxy lan
저작권 © 2024 toptenid.com Inc.
