s김종화z 2016-07

그리고 제가 잘못 알고 있었던건지 모르겠는데...보통 위와 같은 경우에 L4 통해서 들어와도 응답은 L4 안거치고 B 나 C IP 을 가진 이더넷으로 해줘도 문제가 없어야 정상 아닌가요? L7 이 위와 같이 동작하지, L4 는 아니지 않나요?
제가 프로그래머라 장비 쪽 동작은 좀 무지해서...이 부분도 아시는 분 계시면 조언 부탁드립니다.

깡통이 2016-07

음, 문제가 있을 수도 있죠. 클라이언트 입장에서는 패킷을 A로 보냈고, A로부터 온 패킷을 받으려고 기다리고 있는데, 응답이 B나 C라는 IP에서 오니까요.
그래서 B나 C에서 L4 거치지 않고 다이렉트로 보낼때 B나 C가 A에서 보낸 것처럼 눈속임을 하기 위해서 lo:0 같은 걸 설정하는 것이지요.
아마도 언급하신 방식은 서버->L4의 트래픽을 줄이기 위해서 사용하는 것 같은데요, 차라리 서버들을 L4 안쪽으로 두고 NAT기능을 쓰는 것 이 나을 것 같습니다.

s김종화z 2016-07

조언 고맙습니다. 그럼 지금 A 을 통해 들어왔는데 B 나 을 sourceIP 로 해서 나가는건 프로그램 상의 문제로 보는게 맞는 걸까요?

아래 댓글 달아주신 것을 봐도...장비 차원에서 NAT 을 하지 않고 VIP 을 이용한 가상 장비를 통해서 통신하려고 하는데 프로그램이 가상 장비 쪽으로 안보내면...프로그램을 고쳐야 한다는거죠...

장비를 저희가 세팅하는게 아니라서...우리가 원하는 대로가 아니라, 세팅한 쪽에 맞게 우리가 프로그램을 바꿔야 할 가능성이 큰데...보통 이런 세팅이 통상적인 건가요? 아무래도 Half NAT 로 세팅해놓은 것 같은데, B 나 C IP 는 외부 통신이 아예 불가능한 대역에 있습니다.

깡통이 2016-07

보통 원하시는 기능을 사용하려면 L4 스위치가 다음과 같이 동작을 해야 합니다.
어떤 세션에 대해서 외부 클라이언트의 패킷이 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 스위치를 사용하기 위해 서버쪽에 뭔가 다른 설정을 해야 하는게 불편하기도 하고요.

s김종화z 2016-07

후자의 경우, 가상 이더넷을 통해서 요청이 들어왔는데, 고수준의 네트워크 라이브러리에서 연결에 그냥 응답을 보냈는데 실제 이더넷(eth0)로 응답을 보내버리는데...이게 가상 이더넷이 실제 이더넷에 물려 있는 거라 그런거겠죠? 이 경우 실제 이더넷의 IP 로 외부 인터넷이 안될 경우 응답을 위한 서버->클라이언트 소켓 연결을 추가로 연다던지...하는 추가 작업 같은거 말고 방법이 있을까요? 사례가 궁금합니다.

s김종화z 2016-07

조언 덕분에 엔지니어와 대화가 수월하게 되어서, 서버 프로그램에서 IP(hostname)을 통해 특정 IP 로 binding 해서 시작하도록 변경했더니, 엔지니어가 Ok 했습니다. 정말 고맙습니다!
Source NAT(Full NAT) 로의 변경은 어렵다고 하고(좀 큰 업체인데, 전사 모두 Half NAT 라서 변경하려면 일괄로 다 바꿔야된다고) 저도 국내 업체와 일할 때에는 이런 구성은 본 적이 없어서 좀 당황했습니다.

다만, 서버에서 자신들이 원하는 VIP 을 달고 return 하는건 확인했다는데 뭔가 잘 안되네요. 그 다음은 또 자기들의 네트워크 보안 설정의 문제가 아닐까 싶네요.

덕분에 한 고비 넘겼습니다. 정말 고맙습니다.

깡통이 2016-07

네, 잘 해결 되서 다행이네요.
후자의 경우를 사용할 때에 불편하긴 하지만 장점도 있는데요, 서버쪽에서 클라이언트로 보낼 때 L4 스위치를 거치지 않기 때문에 네트워크 트래픽이 감소하고, 응답 속도도 더 빠릅니다.
아마도 그런 이유 때문에 그 업체에서는 Half NAT 정책을 사용하는 것 같네요.

s김종화z 2016-07

네. 그 쪽 말로도 큰 업체들은 다 후자(DSR 구성이라고 하더라구요)를 쓸텐데...라고 하더라구요.

다른 문제가 생기긴 했습니다.

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 로 응답을 하는 방법이 따로 있는지 궁금합니다. 시스템 엔지니어는 저희 쪽의 문제라고 주장하고 있거든요.