L4 환경을 많이 써보지 않은 상태에서 좀 문제를 겪고 있어서 제가 모르는 점에 대한 조언을 얻고자 글을 올립니다.
[가] 라고 하는 L4 장비가 있는데, A 라는 IP 을 가집니다.
[나], [다] 라는 두 대의 리눅스 장비가 있고, 각각 사설IP 로 B 와 C 라는 IP 을 가집니다. 그래서 각각 eth0 에는 B 와 C 라는 IP 을 가집니다.
보통 리눅스에서 저런 환경이 되면, lo:0 라는 걸 만들고 lo:0 에 VIP 라는 이름으로 A 라는 IP 을 넣어두나요?
저는 주로 웹서버 환경 등에서만 써왔는데, 이번에 소켓을 쓰는데 문제가 되네요. 소켓으로 만든 서버 프로그램이 A 라는 IP 을 통해 L4 거쳐서 리눅스 서버로 요청이 들어갔는데, 리눅스 장비에서 값이 나갈 때 B 와 C IP 로 값이 나가서 L4 로 값이 가질 않아서 클라이언트에게 값이 전달되지 않는다고 하네요.
프로그램에서 연결된 소켓 채널에 그냥 값을 write 해주는게 다인데...
통상적으로 lo:0 와 같이 가상 이더넷을 만들어서 하는게 일반적인지, 그리고 보통 이런 환경에서 정상적으로 요청한 이더넷 쪽으로 보내는 옵션 같은게 있는지...있다면 그런 옵션 이름을 보통 뭐라고 부르는지 궁금합니다.
조언 부탁드립니다.
제가 프로그래머라 장비 쪽 동작은 좀 무지해서...이 부분도 아시는 분 계시면 조언 부탁드립니다.
그래서 B나 C에서 L4 거치지 않고 다이렉트로 보낼때 B나 C가 A에서 보낸 것처럼 눈속임을 하기 위해서 lo:0 같은 걸 설정하는 것이지요.
아마도 언급하신 방식은 서버->L4의 트래픽을 줄이기 위해서 사용하는 것 같은데요, 차라리 서버들을 L4 안쪽으로 두고 NAT기능을 쓰는 것 이 나을 것 같습니다.
아래 댓글 달아주신 것을 봐도...장비 차원에서 NAT 을 하지 않고 VIP 을 이용한 가상 장비를 통해서 통신하려고 하는데 프로그램이 가상 장비 쪽으로 안보내면...프로그램을 고쳐야 한다는거죠...
장비를 저희가 세팅하는게 아니라서...우리가 원하는 대로가 아니라, 세팅한 쪽에 맞게 우리가 프로그램을 바꿔야 할 가능성이 큰데...보통 이런 세팅이 통상적인 건가요? 아무래도 Half NAT 로 세팅해놓은 것 같은데, B 나 C IP 는 외부 통신이 아예 불가능한 대역에 있습니다.
어떤 세션에 대해서 외부 클라이언트의 패킷이 DEST IP를 A로 해서 발송하면, L4는 그 패킷을 수신해서 SRC IP를 A로하고 DEST IP를 B나 C로 바꿔서 다시 보냅니다.
서버측에서는 SRC IP를 자신의 IP로(B 또는 C) 하고, DEST IP는 A로 해서 패킷을 보냅니다. 그럼 L4는 SRC IP를 A로 변경하고, DEST IP를 클라이언트의 IP라 바꿔서 다시 발송합니다.
그런데 말씀하시는 경우는 L4가 패킷을 포워딩할 때 SRC IP를 A로 변경하지 않고 실제 클라이언트의 IP 그대로 사용한 경우입니다.
장비마다 용어가 다른 것 같은데, 보통 이런 개념을 Source NAT라고도 하는 것 같고요, 어떤 장비는 전자의 경우를 FULL NAT, 후자의 경우를 HALF NAT라고도 하는 것 같네요.
님께서 말씀하시는 경우가 아래 글과 같은 것 같네요.
http://blog.naver.com/PostView.nhn?blogId=ky1004&logNo=30030838930&redirect=Dlog&widgetTypeCall=true
전자의 경우로 쓰는 경우가 문제될 가능성이 적긴 하죠. L4 스위치를 사용하기 위해 서버쪽에 뭔가 다른 설정을 해야 하는게 불편하기도 하고요.
Source NAT(Full NAT) 로의 변경은 어렵다고 하고(좀 큰 업체인데, 전사 모두 Half NAT 라서 변경하려면 일괄로 다 바꿔야된다고) 저도 국내 업체와 일할 때에는 이런 구성은 본 적이 없어서 좀 당황했습니다.
다만, 서버에서 자신들이 원하는 VIP 을 달고 return 하는건 확인했다는데 뭔가 잘 안되네요. 그 다음은 또 자기들의 네트워크 보안 설정의 문제가 아닐까 싶네요.
덕분에 한 고비 넘겼습니다. 정말 고맙습니다.
후자의 경우를 사용할 때에 불편하긴 하지만 장점도 있는데요, 서버쪽에서 클라이언트로 보낼 때 L4 스위치를 거치지 않기 때문에 네트워크 트래픽이 감소하고, 응답 속도도 더 빠릅니다.
아마도 그런 이유 때문에 그 업체에서는 Half NAT 정책을 사용하는 것 같네요.
다른 문제가 생기긴 했습니다.
VIP 쪽으로 바인딩 해버리니 VIP 가 설정된 interface 쪽의 요청만 수신해서...L4 의 live check 가 안된다고 하네요. live check 는 또 eth0 쪽을 통해서(그것도 VIP 가 올라간 쪽만 특정해서) 한다고 하네요. 그래서 이걸로 또 반나절 소모했습니다. 이게 보편적인지 궁금하네요.
관련해서...프로그램 쪽 내용은 아래에 덧붙이겠습니다(혹시 다른 분께 도움이 될까봐요).
여러모로 도움 주셔서 정말 고맙습니다.
------------------------------------------------------------------------------------
먼저, 거의 동시간에 올린 게시물로 이 문제는 해결했습니다. Bootstrap 의 bind() 에 port 뿐만 아니라 hostname 을 매개변수로 받을 수 있는데, 이 hostname 에 명시된 interface 로만 통신하도록 binding 할 수 있었고, 이 옵션으로 원하는 대로 A IP 로 outbount 가 되도록 하였습니다.
그러나 여전히 남는 문제는, 분명 L4 에서 A 라는 IP 로 요청을 보냈음에도 B 라는 IP 로 값을 되돌려준다는 것입니다. A 라는 IP 가 B 라는 IP 가 설정된 eth0 위에 가상으로 생성된 lo:0 에서 나온 것이기 때문에 결국 외부->A->B->Netty 로 들어갔다는 것은 맞는데, Netty->B->외부 처럼 리턴에서 A 가 빠져버림으로써 문제가 야기되었습니다. B 는 외부로 데이터를 내보낼 수 없는 회선이기 때문입니다.
그리고, 이후에 문제가 발생했는데...L4 에서 장비의 live 확인을 B 을 통해서 한다고 합니다. 그것도 lo:0 가 올라간 상태에서만 가능하기 때문에 bind() 로 A IP 로만 열어둔 상태에선 B 로 해당 포트로 접속이 안되서 L4 에서 서버가 down 된 것으로 판단해서 dead 처리를 해버린다고 하네요.
다른 언어에서나 기본 Java 에서는 어떻게 처리되는지는 모르겠으나, Netty 의 이런 방식에 문제가 있는건지, 아니면 A 로 들어오면 A 로, B 로 들어오면 B 로 응답을 하는 방법이 따로 있는지 궁금합니다. 시스템 엔지니어는 저희 쪽의 문제라고 주장하고 있거든요.