개요

처음 패킷을 뜯어볼 때 너무 의외여서 감을 잡는데 오래 걸린 부분이 있다.
ztunnel에서 다른 ztunnel의 15008포트로 날린 것으로 보이는 트래픽이 파드 내부에서 포착됐기 때문.
E-앰비언트 ztunnel 트래픽 경로 분석 참고.

이것 때문에 이게 무슨 상황인가, 너무 헷갈렸다.
아키텍처 설명 글을 보면 ztunnel은 파드 네임스페이스에 리스너 소켓만 생성한다고 했던 것 같은데, 그것만으로는 도저히 이 상황이 이해되지 않았다.
단순히 리스너 소켓만 만들어서 받아내는 것이 아닌 것으로 보인다.
요청을 처리하는 소켓을 둘 때 setns를 한 것이 이후 요청을 처리할 때도 전파된다고 해석해야 할까?
혹시 소켓이 양방향 통신을 할 수 있는 거라도 되나 싶었는데, 임의의 포트를 받는다는 것은 결국 클라 측에서 connect를 하는 동작으로 해석해야 한다고 본다.
애초에 tcp 리스닝 소켓으로 새로 요청을 한다는 발상도 말이 안 되고, 된다 한들 어떻게 인터페이스를 지나는 시점에 ip와 포트를 조작할 수 있는 것인지 해석이 되지 않는다.

배경

이렇게까지 내가 의문을 가지게 된 것은 이 그림 때문이다.^[1]

이 그림만 봐서는 꼭 소켓 하나로 모든 통신을 감당해낸다는 것처럼 보인다.
하지만 막상 패킷을 캡쳐했을 때 임의의 포트가 추적됐기 때문에 이 부분을 이해하고자 한참 삽질했다.
현재 내 결론이 맞다면, 이 그림 그린 사람은 살짝 혼나야 된다

코드 분석

내가 소켓에 대해 잘 이해를 못해서 그런 건가 싶어서 관련 글들을 찾아본 이후에, ztunnel이 실제로 요청을 파드의 네임스페이스 자원을 활용해서 보낸다고 판단했다.
그래서 얕게나마 러스트 코드 분석을 시도했다.
여태 추적한 내용을 정리하자면..

아웃바운드 인스턴스를 만들 때 리스너를 가져온다.^[2]
이 코드는 비동기로 실행되는데, 이때 실행되는 코드 블록 단위로 네임스페이스가 세팅되는 것이 아닌가 생각한다.

해당 인스턴의 run 메소드는 리스너 소켓의 accecpt를 함과 동시에 OuboundConnection을 세팅한다.

그리고 OutboundConnection의 proxy_to 메소드가 HBONE으로 보내던, 웨이포인트로 보내던, 그냥 보내던 동작을 한다.

리스너를 가져올 때 bind 동작은 내부에 configure 메소드를 먼저 동작시킨다.^[3]

해당 메서드가 네임스페이스에 들어가 소켓을 세팅한다.

잠시 여담으로 이 부분에서 소켓을 세팅하면서 패킷 마킹 작업이 일어나는 것을 확인할 수 있다.
해당 코드를 따라 들어가다보면 InPodMark로 1337을 설정하는 것을 볼 수 있다.
(1337을 16진수로하면 0x539이다.)

netns.run 메서드는 간단하게 setns를 할 뿐이다.^[4]

결론

코드로만 봐서 사실 명확하게 판단을 내리기는 어렵다.
하지만 앞서 패킷을 뜯어본 바 파드의 네임스페이스에서 추적될 수 있도록 패킷 정보는 분명하게 출력되고 있다.
인터페이스 역시 네임스페이스 단위로 분리가 되는 것은 명확하다.
그렇다면 결국 아웃바운드 트래픽을 받아 ztunnel이 만드는 새로운 요청 역시 해당 네임스페이스에서 실행되는 것이라는 것이 내 결론이다.
이 부분을 다시 정리하자면, ztunnel은 사실 파드의 네임스페이스에 리스너 소켓만 만들고 더 이상 관여를 하지 않는 것이 아니다.
오히려 ztunnel 자체가 이루는 요청도 파드에서 나가는 것처럼 네트워크 영역을 세팅한다.

한편으로 생각해봤을 때는 이 동작은 매우 자연스러운 방식이다.
왜냐하면 ztunnel이 전송 간 암호화를 한다는 것은 결국 파드 바깥으로 트래픽이 나가는 순간 패킷이 암호화돼야 한다는 것을 뜻한다.
그렇다면 그러한 암호화된 패킷은 파드의 네트워크 네임스페이스를 통해서 나가는 것이 응당 자연스럽고, 목적에 부합한 동작이다.

관련 문서

지식 문서, EXPLAIN

기타 문서

참고