VPN 노트북이 더 빨라지려면 IP 포워딩이 필요한가?
포워딩은 인터페이스 사이로 패킷을 넘길 뿐, 로컬 브라우저를 빠르게 하지 않습니다. 규칙을 넓히기 전에 클라이언트 역할과 게이트웨이 역할을 분리하세요.
노트북을 라우터로 만드는 것은 잘못된 문제를 푸는 흔한 방식입니다. 포워딩은 목적지가 자기 자신이 아닌 패킷을 기계가 넘길 수 있도록 존재하며, 같은 기계의 브라우저가 페이지를 얼마나 빨리 불러오는지에 대해서는 아무 의견이 없습니다. 두 경로가 비슷해 보이는 것은 둘 다 하나의 터널로 트래픽을 보내기 때문일 뿐입니다. 한 번 분리해 보면 포워딩을 켜거나 방화벽을 여는 것에 관한 조언 상당수가 가지고 있지도 않은 구성을 설명하고 있음을 알게 됩니다.
책상에서 보면 똑같아 보이는 두 패킷 경로
노트북의 브라우저는 스스로 요청을 만듭니다. 호스트가 터널 경로를 고르고, 클라이언트 프로세스가 패킷을 감싸 상대에게 보내며, 응답이 애플리케이션으로 돌아옵니다. 이 순서에는 포워딩 결정을 지나는 지점이 없습니다. 이 기계가 대화의 출발점이자 도착점이기 때문입니다.
이제 의도적으로 구성한 이더넷 세그먼트에 다른 장치를 두고 노트북을 그 기본 게이트웨이로 만드세요. 그 장치가 요청을 시작하고, 노트북은 다른 곳으로 향한 패킷을 받으며, 커널이 그것을 넘길지 결정해야 합니다. 이것이 포워딩 역할이고, 클라이언트 역할에는 결코 필요 없던 전제가 따라붙습니다. 허용된 통과 경로, 양쪽의 경로, 그리고 변환이 설계의 일부라면 여전히 동작하는 귀환 경로입니다.
| Role | Who originates the traffic | What has to be true |
|---|---|---|
| Client only | The laptop itself | Tunnel route, working resolver, supported profile |
| Gateway | Another device | Forwarding enabled, permitted transit, routes both ways, return-path decision |
ip_forward가 실제로 바꾸는 것
커널의 IPv4 sysctl 문서는 ip_forward를 호스트가 인터페이스 사이로 패킷을 포워딩하게 하는 스위치로 설명합니다. 호스트 스스로 만든 트래픽을 위한 빠른 길이 아니며, 그 매개변수를 어떻게 읽어도 로컬 브라우저가 빨라지지 않습니다. 오히려 포워딩은 전보다 적은 일을 하던 기계에 상태와 정책을 더합니다.
같은 문서는 값을 바꾸면 다른 IPv4 매개변수가 호스트나 라우터의 기본값으로 되돌아간다고 경고합니다. 그래서 이 스위치는 시험이 아니라 구성 사건입니다. 조정해 둔 설정이 발밑에서 되돌아갈 수 있고, 그 변경이 누구도 거기에 돌리지 않을 회귀의 원인이 될 수 있습니다. 또한 스위치는 게이트웨이 역할을 가진 사람이 한 번, 의도적으로 설정해야 한다는 뜻입니다. 느려짐을 조사하는 중에 이것을 뒤집는 것은 부작용이 증상과 뒤섞이는 것이 보장된 유일한 경우입니다.
같은 질문이 아닌 세 가지 방화벽 질문
VPN 수신을 허용하는 것, 노트북이 실행하는 서비스를 허용하는 것, 트래픽이 노트북을 지나가도록 허용하는 것은 세 가지 별개의 허가입니다. 첫째는 상대가 데몬에 닿게 하고, 둘째는 로컬의 무언가를 드러내며, 셋째는 기계를 다른 누군가의 통과 지점으로 바꿉니다. 각각 범위가 다르고, 마지막 것은 평범한 외부 응용에 필요한 응답보다 훨씬 넓습니다.
특정 흐름이 막혔을 때는 규칙을 고치기 전에 그 출발지, 목적지, 방향, 정책 소유자를 밝히세요. 그 흐름을 위한 좁은 규칙은 수정입니다. 터널 인터페이스에서 모든 것을 받아들이는 것은 우연히 수정을 포함하는 정책 변경입니다. 그 뒤에 동작하는 브라우저는 흐름이 동작함을 보여 줄 뿐, 넓은 규칙이 필요했다는 증거는 아닙니다.
경로가 맞은 뒤에만 측정하세요
같은 목적지, 같은 작업 부하, 비교 가능한 조건으로 측정하고 한 번에 하나의 변수만 바꾸세요. 포워딩 변경, 방화벽 확장, 복사한 암호 설정을 한꺼번에 묶은 시험은 숫자만 내놓고 설명은 내놓지 않습니다. 세 가지 중 무엇이 결과를 움직였는지 아무것도 말해 주지 않기 때문입니다.
경로와 리졸버 실패는 성능 이야기에서 완전히 빼 두세요. 느리게 해석되는 이름은 처리량 문제가 아니고, 한 고정 크기에서 멈추는 전송은 보통 속도 한도가 아니라 MTU 문제입니다. 어떤 숫자를 비교하기 전에 이 세 가지 중 무엇을 실제로 관찰했는지 적어 두세요. 그러지 않으면 다음 독자는 잘못된 것을 재는 측정과 아무도 정당화할 수 없는 변경을 물려받습니다.
클라이언트에 붙은 이름표가 아니라 지금 가진 구성을 설명하세요
자기 연결을 공유하거나, 라우팅된 컨테이너 네트워크를 호스트하거나, 가상 머신의 트래픽을 나르는 노트북은 소프트웨어가 스스로를 무엇이라 부르든 게이트웨이입니다. 클라이언트라는 말은 터널이 어떻게 구성되었는지를 말할 뿐, 패킷이 다른 누군가에게 넘어가는지는 말하지 않습니다.
운영 지침에서 역할을 분명히 하세요. 무엇이 트래픽을 만들고, 무엇이 기계를 통과해야 하며, 지금 하는 일이 둘 중 어느 쪽에 관한 것인지 적습니다. 지원되는 계획에 속할 때만 게이트웨이 역할을 켜고, 필요했던 적 없는 구성에 설명 없는 속도 조정으로 적용하지 마세요.