많은 앱 연결이 하나의 OpenVPN 세션을 공유하는 이유

브라우저가 HTTPS 페이지를 불러오는 동안 SSH 클라이언트가 다른 서버에 닿고 리졸버가 질의에 답하는 상황이 모두 하나의 OpenVPN 세션을 지나간다고 상상해 보십시오. 물리 인터페이스에서는 대화가 하나 보이고, 터널 안에서는 셋이 보입니다. 두 관점 모두 옳으며, 왜 그런지 아는 것이 쓸모 있는 캡처와 혼란스러운 캡처를 가르는 차이입니다. 내부 흐름 하나를 소켓에서 선로까지 따라가면 계층 구조는 더 이상 추상적이지 않습니다.

외부 대화 하나, 내부 흐름 여럿

각 애플리케이션은 자기 소켓을 열고, 커널은 출발지 주소, 출발지 포트, 목적지 주소, 목적지 포트, 프로토콜의 다섯 요소로 된 튜플을 부여합니다. 이 튜플은 어떤 터널이 개입하기 전부터 존재합니다. 그다음 라우팅이 이들 모두가 터널 장치를 통해 나간다고 결정하므로, OpenVPN에 넘겨지는 패킷은 여전히 원래 헤더를 안에 지니고 있습니다. OpenVPN은 그 내부 패킷을 암호화하고 결과를 피어와의 단일 외부 UDP 또는 TCP 대화로 감쌉니다. 따라서 외부 대화는 하나이고, 그 안의 흐름은 애플리케이션이 연 수만큼입니다.

무엇도 무너지지 않습니다. 내부 튜플은 끝에서 끝까지 살아남으며, 그래서 먼 쪽은 여전히 세 흐름을 구별할 수 있습니다.

고정된 채로 남는 포트

일정하게 남는 것은 외부 튜플, 곧 여러분의 주소, 클라이언트가 묶은 로컬 포트, 피어 주소, 그리고 설정된 서비스 포트입니다. 경로상의 방화벽이나 NAT가 허용해야 하는 것이 바로 이 튜플이며, 업링크에서 찍은 캡처가 보여 주는 것도 이것입니다. 재접속이나 네트워크 전환 뒤에 바뀌는 것도 이것인데, 클라이언트가 다른 로컬 포트를 묶을 수 있기 때문입니다. 터널이 하나라고 해서 출발지 포트가 영원히 하나로 고정되는 것은 아닙니다.

끝점이 신경 쓰는 것은 내부 포트입니다. HTTPS 흐름은 외부 전송이 운영자가 설정한 포트에 앉아 있어도 터널 안에서는 목적지 포트 443을 유지합니다. 애플리케이션 끝점은 외부 포트를 결코 알지 못합니다.

먼 쪽에서 역캡슐화가 바꾸는 것

피어에서는 외부 계층이 벗겨지고 남는 것은 내부 패킷입니다. 거기서부터 전달과 접근 정책이 내부 목적지와 프로토콜에 적용됩니다. 웹 서버는 여전히 HTTPS 연결을 받고, SSH 데몬은 여전히 SSH를 받으며, 리졸버는 여전히 질의를 받습니다.

그래서 외부 전송을 허용하는 규칙은 내부 서비스를 허용하는 규칙과 같지 않습니다. 앞의 것은 경로를 설명하고, 뒤의 것은 권한을 설명합니다.

외부 TCP는 하나의 흐름이지 하나의 연결이 아닙니다

외부 전송이 UDP일 때 각 내부 흐름의 운명은 독립적이어서, 잃어버린 데이터그램은 자기 재전송까지 하나의 전송에만 영향을 줍니다. 외부 전송이 TCP일 때는 모든 내부 흐름이 하나의 신뢰할 수 있는 바이트 스트림을 공유합니다.

그 공유 스트림이 사람들이 놓치는 부분입니다. 복구가 모든 것에 대해 한 번만 일어나므로, 세그먼트 하나가 유실되면 그 안에서 다중화된 모든 애플리케이션의 트래픽이 지연됩니다. 끝점에서는 여전히 연결이 많고 선로에서는 연결이 하나이며, 선로 위에서 머리 막힘 효과가 살아 있습니다. 수신 대기 포트 수는 이에 대해 아무것도 알려 주지 않으며, 그래서 포트를 세는 것은 터널 성능을 따지는 나쁜 방법입니다.

자기 구성은 정확히 설명하십시오

기계가 모든 것을 하나의 포트로 보낸다고 말하는 대신, 선택한 내부 트래픽과 그것을 나르는 구체적인 외부 전송을 지목하십시오. 로컬 서비스, 두 번째 터널, 다른 주소 체계는 모두 이 대화에 들어오지 않는 흐름을 만듭니다. 업링크의 캡처는 외부 튜플을 보여 주고, 터널 안의 캡처는 내부 튜플을 보여 줍니다.

둘 다 떠서 타임스탬프를 나란히 놓으십시오. 어느 애플리케이션이 어느 내부 흐름을 만들었는지 증명해야 한다면, 포트를 프로세스에 직접 대응시키는 호스트의 소켓 표가 더 나은 도구입니다. 그다음, 재접속 뒤의 다음 캡처가 다른 숫자를 보여 주는 것은 정당하므로, 관찰한 외부 튜플과 관찰한 순간을 적어 두십시오.