VPN 흐름에서 클라이언트 소스 포트와 서버 리스너
하나의 터널에 나타나는 두 포트 번호, 즉 서버의 고정 리스너와 클라이언트의 임시 소스를 비교하고 그 사이에서 라우터 변환이 어떻게 자리하는지 정리합니다.
같은 대화에 두 개의 번호가 나타나며 둘 다 틀리지 않았습니다. 서버 로그에는 서비스를 제공하는 리스너가, 노트북에는 데이터그램을 보낸 소켓이 표시되고, 그 사이의 라우터가 나가는 길에 두 번째 번호를 다시 쓸 수 있습니다. 숫자 자체를 비교하는 것보다 대화의 양 끝을 비교하는 편이 더 유용합니다. 아래 비교는 리스너, 클라이언트 소켓, 변환된 소스를 분리해 다룹니다. 서로 다른 질문에 답하기 때문입니다.
반대쪽 끝을 설명하는 두 개의 번호
서버에 설정된 포트는 클라이언트가 연결하는 목적지입니다. 정책으로 고정되고 프로필에 나타나며 서버 쪽에서 열려 있어야 합니다. 클라이언트의 소스 포트는 로컬에서, 보통 임시 범위에서 선택되며 응답이 돌아올 자리를 만들기 위해 존재합니다. 재연결마다 바뀔 수 있고, 설계 어디도 그것이 안정적이라고 가정하지 않습니다.
중간의 라우터는 그 소스를 자신의 'NAT' 매핑으로 다시 쓸 수 있습니다. 그래서 서버에서 보이는 번호가 노트북이 고른 번호와 무관한 경우가 많습니다.
나가는 길에 소스 번호가 바뀌는 지점
가상의 IPv4 예를 들어 봅시다. 변환하는 라우터 뒤의 클라이언트, 'UDP' 리스너 하나를 가진 서버, 둘을 모두 지나는 데이터그램 하나입니다. 표는 세 관측 지점에서 패킷을 다시 재생하는 대신 각 끝점과 그곳에서 일어나는 일을 지목합니다.
| Endpoint | What stays fixed | What changes on reconnect | Who owns it |
|---|---|---|---|
| Server listener | The service port and the address the profile names | Nothing; the listener does not follow the client | The server operator |
| Client socket | The destination it dials | The local source port, chosen per socket | The client, or its operating system |
| Translated source | Usually the public address of the router | The port, and sometimes the address after a network switch | The NAT device or the upstream carrier |
목적지는 모든 행에서 일정하고, 바뀌는 것은 소스의 정체성뿐입니다. UDP NAT 요구 사항은 내부 주소와 포트를 외부 매핑과 구분하며, 이는 두 번째와 세 번째 행의 차이 그 자체입니다. 라우터는 클라이언트의 소스 포트를 유지할 수도, 다른 것을 고를 수도 있습니다. 유지된다고 애플리케이션이 가정해서는 안 됩니다.
세 끝점을 호스트 자체에서 읽기
아래 목록은 서로 다른 세 대의 장비에서 가져온 것이며 함께 전체 대화를 보여 줍니다. 첫 번째는 서버에서, 두 번째는 클라이언트에서, 세 번째는 매핑이 존재하는 곳에서 실행합니다. 한 줄의 로그로 세 가지가 모두 드러나지는 않습니다.
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194첫 번째 목록은 서버가 서비스 포트에 묶여 있음을 증명하고 어떤 프로세스가 그것을 소유하는지 보여 줍니다. 두 번째는 클라이언트의 로컬 소켓과 연결한 목적지를 보여 줍니다. 세 번째는 라우터가 만든 매핑을 보여 주며, 변환된 소스가 나타나는 유일한 곳입니다. 이 순서로 읽으면 두 번호가 더 이상 모순되어 보이지 않습니다.
재연결이 바꾸는 것과 바꾸지 않는 것
일부 라우터는 소스 포트가 비어 있으면 유지하고, 일부는 매번 다른 포트를 할당합니다. 두 동작 모두 정상이며, 전자를 요구하는 애플리케이션은 후자에서 깨집니다. 재연결이나 네트워크 전환 뒤의 매핑 변화는 서버 결함이 아닙니다. 클라이언트가 새 소켓을 열고, 라우터가 가진 것을 할당하며, 서버는 같은 리스너에서 새 소스를 봅니다. 결함이라면 서버가 임의의 클라이언트 포트로 향한 트래픽을 받아들일 것이라고 기대하는 쪽입니다.
커뮤니티의 OpenVPN 클라이언트는 nobind을 통해 이 동작을 얻습니다. 로컬 포트 선택을 운영 체제에 맡기는 설정이며, 원격 포트는 여전히 프로필에서 옵니다. 명시적으로 바인딩하는 것은 의도적인 선택이지 프로토콜 요구 사항이 아닙니다. 서버는 하나의 끝점을 계속 제공하고 클라이언트는 각자의 로컬 정체성을 고릅니다.
기록에서 계층을 따로 표시하기
터널 안에는 자체 포트를 가진 두 번째 대화가 있습니다. 터널이 나르는 HTTPS 요청의 목적지는 TCP 443이고, 바깥 암호화 연결은 UDP 1194를 사용하므로 바깥 소스 포트를 바꿔도 안쪽 서비스에는 아무 영향이 없습니다.
바깥 계층에서도 프로토콜이 중요합니다. UDP 1194와 TCP 1194는 서로 다른 끝점이며, 번호가 같다는 이유만으로 'TCP' 리스너가 UDP 데이터그램을 받지는 않습니다. 배포를 문서화할 때 서버 리스너, 클라이언트 소켓, 변환된 소스를 세 가지 별개로 표시하고 각각에 전송 방식을 덧붙이십시오.
그다음 정책이 역할을 따르게 하십시오. 서버는 리스너에서 의도한 전송 방식을 열고 여전히 상대를 인증합니다. 클라이언트의 방화벽은 인바운드 서비스를 공개하지 않은 채 자신의 아웃바운드 교환에 대한 응답을 허용합니다. 상태 없는 필터에는 반환 방향을 명시해야 하며, 정돈된 그림 밖에서도 이 구분이 중요한 실무적 이유가 바로 여기에 있습니다.