게이트웨이에서 OpenVPN 클라이언트 트래픽을 어디서 볼까

연결된 클라이언트가 어떤 목적지에 도달하는지 알고 싶어 VPN 서버에서 셸을 열고 ss를 입력합니다. 유용한 것은 아무것도 나타나지 않고, 터널이 고장 났다는 결론은 조금 너무 쉽게 따라옵니다. 라우팅 OpenVPN 게이트웨이는 클라이언트의 패킷을 전달합니다: 그 패킷의 TCP 연결을 종료하지 않고 그들을 위한 소켓도 갖지 않습니다. 증거는 다른 곳에 살고, 그 다른 곳이 어디인지는 트래픽이 터널을 떠난 뒤 어떻게 처리되는지에 달려 있습니다.

어떤 구성인지 먼저 판단하세요

흔한 두 형태는 전혀 다른 증거를 만듭니다. 라우팅 게이트웨이는 캡슐을 풀어 전달하고 경우에 따라 출발지 NAT를 수행하므로 클라이언트의 연결은 로컬 소켓 없이 끝에서 끝까지 유지됩니다.

프록시는 트래픽을 종료합니다: 연결을 받아들이고 다음으로 자기 자신의 상위 연결을 엽니다. 그 구성에서는 한 요청에 연결이 둘이고, 둘 사이의 연관은 프록시 자체 기록에만 존재합니다. 둘 중 무엇을 배포했는지 알면 커널의 흐름 상태를 읽어야 하는지 애플리케이션 로그를 읽어야 하는지가 정해집니다.

혼란의 대부분은 추측에서 옵니다. 도구를 고르기 전에 형태를 확인하세요. 그 존재가 이후의 모든 단계를 바꾸므로, 먼저 서버 구성에서 프록시 지시문이 있는지 읽으세요. 그것이 없으면 패킷 경로는 라우팅이고 커널의 흐름 상태가 당신의 증거입니다.

먼저 주소를 세션에 묶으세요

서버의 세션 상태에서 시작해 클라이언트의 현재 내부 주소를 확인하세요. 풀 주소는 재사용되므로 주소만으로는 임대일 뿐 사람이 아닙니다.

시간과 인증된 신원을 함께 기록하고, 그 클라이언트 뒤에 LAN 전체가 숨어 있는지 살펴보세요. 원격 쪽이 서브넷을 라우팅한다면 당신이 보는 내부 주소는 원래 호스트이거나 변환된 것일 수 있습니다.

ip -4 addr show dev tun0
journalctl -u [email protected] --since '-10 min' | tail -n 40

그 쌍은 두 가지 질문에 동시에 답합니다: 터널 인터페이스가 어떤 프리픽스를 제공하는지, 그리고 당신이 관심 있는 구간에 어떤 세션이 활성이었는지입니다. 잘못된 세션에 붙은 그럴듯한 튜플은 증거가 전혀 없는 것보다 나쁘므로, 어떤 흐름 항목이든 해석하기 전에 이렇게 하세요.

라우팅 게이트웨이에서 흐름 표를 읽으세요

주소와 구간이 정해지면 추적된 연결의 읽기 전용 목록이 게이트웨이가 그 주소를 위해 무엇을 전달하는지 보여줍니다. 표 전체를 읽지 않도록 원래 출발지로 필터링하세요.

sudo conntrack -L -p tcp -f ipv4 --orig-src 10.8.0.37

각 항목은 원본과 응답 두 튜플을 담고 있으며, 이는 한 흐름의 두 방향이고 두 애플리케이션이 아닙니다. 출발지 NAT 경로에서는 원본 튜플이 터널 주소를 유지하고 응답 쪽은 변환된 게이트웨이 주소를 보여 주며, 바로 그래서 출력이 언뜻 잘못되어 보입니다.

목록을 이력이 아니라 살아 있는 상태로 다루세요. 짧은 흐름은 이미 만료되었을 수 있고, 추적되지 않은 트래픽은 절대 나타나지 않으며, 다른 네트워크 네임스페이스는 다른 표를 보여줍니다. conntrack 참조가 필터와 양방향 출력을 문서화합니다.

읽기를 확인할 한 번의 제한된 캡처

터널 인터페이스가 당신이 보는 곳에 보인다면, 제한된 캡처 한 번으로 당신이 식별한 패킷이 회선 위의 것인지 판정됩니다. 필터는 좁게, 패킷 한도는 작게 유지하세요.

sudo tcpdump -ni tun0 -nn -c 50 'host 10.8.0.37 and tcp'

타임스탬프, 프로토콜, 포트를 흐름 항목과 그리고 테스트로 보낸 요청과 비교하세요. NAT 이후에 찍은 캡처는 게이트웨이의 공인 주소만 보여 주고, 터널 쪽은 여전히 클라이언트의 주소를 보여 줄 수 있으며, 그 차이는 모순이 아니라 정보입니다.

인터페이스가 아무것도 보지 못한다면 클라이언트 간 트래픽과 일부 오프로드 경로가 당신이 지켜보는 지점을 결코 지나지 않으므로, 클라이언트가 유휴하다고 결론 내리기 전에 데이터 경로를 확인하세요.

프록시 로그, 그리고 당신이 본 것의 한계

프록시가 경로에 있으면 그 상위 소켓은 소켓 표에 보이지만, 특히 풀링이나 다중화에서는 VPN 클라이언트와 일대일로 대응하지 않습니다. 프록시에 설정된 트랜잭션 로그를 사용해 클라이언트 신원, 목적지, 타임스탬프, 기록되는 요청 식별자를 연관시키세요.

모든 요청이 기본으로 기록된다고 가정하지 말고 배포된 버전의 로깅 구성을 확인하세요.

마지막으로 범위에 대해 정확하세요. 내부 HTTPS 세션이 터널과 무관하게 자체 보호를 유지하므로, 목적지 주소와 포트는 메타데이터이며 URL도 페이지 내용도 아닙니다. 무엇을 관찰했는지, 어느 관측 지점에서, 어느 시각에 보고하세요.