Cloud servers commonly have different interface IP and inner IPs.
When read / create session, session IP (HTTP_HOST / X-FORWARDED-HTTP) can be differ from server IPs.
reported by 건더기
이슈 등록시간: 2011-05-22T14:46:08.560165
마지막 수정시간: 2011-05-22T14:56:15.990606
Comment 1 by inureyes at 2011-05-22T14:47:19.952735
Comment from 건더기
----
아마존 EC2 환경 무료 성능체험 (Free Usage Tier)를 통해 Micro instance를 BMT 하려고 하고 있습니다...
텍스트큐브 세팅하다가 앞으로 클라우드 환경의 모든 가상 서버에서 발생할 수 있는 상황에서의 세션관련 버그를 하나 찾아내 메일 날립니다.
EC2는 기존의 가상서버 호스팅과는 달리 각각의 가상 서버에는 고정된 IP가 주어지지 않습니다.
각각의 서버에 가상IP와 공인IP를 다 부여해주기는 하지만, 부팅때마다 새로 할당받기 때문에 얼마든지 재부팅만으로도 할당된 IP가 바뀝니다.
이를 위해 AWS EC2에는 각 서버당 하나만 연결되는 Elastic IP라는 서비스가 존재합니다.
이 IP는 각 지역 IDC별로 최대 5개 까지만 사용 가능하고, 각각의 가상서버(instance)와 연결하면 재부팅을 하더라도 바로 이 Elastic IP(고정 공인 IP)로 접속하면 자동으로 서버로 트래픽이 연결됩니다.
이 과정을 아마존이 어떻게 처리했는지, 최종적으로 서버에서 리모트 정보는 모두 원래 접속한 클라이언트의 것을 받아옵니다.
X-Forwarded-for를 쓸 필요가 없어지는 것이죠.
문제는 이 경우 서버 내부에서 인식하는 IP는 유동적으로 부여받는 가상 IP인데, 서버 외부에서는 Elastic IP로 서버를 호출했고, 서버에도 그 Elastic IP로 접속들어온 것으로 기록이 남습니다.
바로 이 대목에서 세션에 문제가 생깁니다....
원격지 IP는 그대로 있어서 상관없는데, 정작 원격지에서 호출하는 서버 IP와 서버 내부에서 인식하는 SERVER_ADDR에서 잡히는 서버 IP가 달라서 세션 생성에 오류가 생기는겁니다 ;;;;;
차라리 상단 스위치에서 패킷 원산지까지 세탁하는 방식으로 해두었으면 그냥 X-Forwarded-for를 도입해버리면 간단한데, 그게 아니라 문제군요 ;;;;;;
이 부분은 외부 IP와 서버 IP가 다른데 스위치 차원에서 그냥 쏴주는 동일 방식의 클라우드 호스팅에서는 동일하게 문제가 생깁니다.
Comment 2 by inureyes at 2011-05-22T14:47:36.741257
Reduce security barrier to support cloud? Is it the only solution?
Comment 3 by inureyes at 2011-05-22T14:56:15.990606
In 651fb4c206b0fb0fa3c4c8e9974d1f5a4f1a83bc
:
#!CommitTicketReference repository="" revision="35bfe877900f727e2472b3481c9d0c707b896f44"
refs #1585 : Modify : Session module does not check the IP-based server-client matching.
Summary