하나의 IPv4 목적지를 OpenVPN 터널 밖으로 보내는 방법

대부분의 전체 터널 설정은 모든 패킷을 VPN을 통해 보내며, redirect-gateway가 바로 그렇게 만드는 지시어입니다. 단일 목적지는 여전히 예외로 둘 수 있습니다. 해당 주소에 net_gateway 자리 표시자를 사용한 호스트 경로를 추가하면 클라이언트는 머신의 원래 게이트웨이를 통해 그 주소에 도달하고, 나머지는 계속 터널을 사용합니다.

이 줄은 무해해 보이고 실제로 그런 경우가 많지만, 오직 한 가지 질문만 해결합니다: 정확히 그 IPv4 주소로 가는 패킷이 어디로 향하는가입니다. DNS, IPv6, 방화벽 정책, 어떤 프로세스가 연결을 열었는지는 바꾸지 않으며, 그 각각이 예외를 조용히 무력화할 수 있습니다.

net_gateway가 실제로 가리키는 것

그 예외에 대한 프로필 항목은 한 줄입니다: route 198.51.100.77 255.255.255.255 net_gateway. 첫 번째 주소는 목적지를 위한 문서용 자리 표시자이고, 마스크는 이를 단일 호스트 경로로 만들며, 마지막 토큰은 게이트웨이 자리 표시자를 가리킵니다. OpenVPN은 경로를 설치할 때 게이트웨이 자리 표시자를 해석합니다. vpn_gateway는 터널 자체의 게이트웨이, 즉 VPN 링크의 반대편을 의미합니다. net_gateway는 VPN이 무언가를 바꾸기 전에 호스트가 가지고 있던 기본 게이트웨이를 의미하며, 보통 물리 네트워크의 로컬 라우터입니다.

세 번째 자리 표시자인 remote_host는 VPN 서버의 주소를 가리키며, 터널이 물리 경로로 서버에 도달할 수 있도록 존재합니다. 이 셋을 혼동하는 것이 예외가 잘못된 곳으로 가거나 아예 설치되지 않는 가장 흔한 이유입니다.

값은 연결할 때 읽히며 파일에 기록되지 않습니다. 머신이 다른 네트워크로 이동하면 VPN 이전의 게이트웨이가 바뀌고 경로는 새 게이트웨이를 따릅니다. 보통은 원하는 동작이지만, 예외의 동작이 클라이언트가 시작한 네트워크에 달려 있다는 뜻이기도 합니다.

호스트 경로가 터널의 기본 경로를 이기는 이유

라우팅은 가장 구체적으로 일치하는 접두사로 결정됩니다. redirect-gateway def1은 보통 기본 경로를 대체하지 않고, 주소 공간의 아래쪽 절반에 대한 경로와 위쪽 절반에 대한 경로, 두 개의 절반을 추가하므로 원래 기본 경로는 다른 용도로 남습니다. 그 절반은 단일 주소보다 넓습니다.

마스크 255.255.255.255를 사용하는 단일 주소 경로는 /32이며, 이는 IPv4가 가질 수 있는 최대 구체성입니다. 해당 주소의 패킷을 평가할 때 /32가 일치하고 어느 경로가 먼저 설치되었든 이깁니다. 이것이 예외의 메커니즘이며, 경로가 실제로 존재하는 한 Linux, macOS, Windows에서 동일하게 작동합니다.

Windows는 두 번째 차원을 더합니다. 두 경로가 같은 수준으로 구체적이면 메트릭이 낮은 쪽이 이기며, VPN 어댑터가 결과를 바꾸는 인터페이스 메트릭을 가질 수 있습니다. /32는 여전히 절반보다 구체적이므로 예외는 보통 유지되지만, 이전 세션의 오래된 경로가 같은 수준으로 구체적이면 혼란스러운 결과를 낼 수 있습니다.

예외가 다루지 않는 것

DNS가 첫 번째 틈입니다. 클라이언트가 내부 리졸버 설정을 밀어 넣을 수 있고, 운영체제는 조회에 계속 그것을 사용합니다. 연결 전에 이름을 해석하는 애플리케이션은 직접 가야 할 서비스에 내부 주소를 받거나, 올바르게 해석되지만 다음 틈에서 걸려 넘어지는 외부 주소를 받을 수 있습니다.

IPv6가 두 번째입니다. 경로 지시어는 IPv4만 다룹니다. 이중 스택 목적지는 IPv6를 선호할 수 있으며, 정책에 따라 터널이나 호스트의 IPv6 기본 경로를 따르므로 IPv4 예외는 결코 적용되지 않습니다. 일치하는 IPv6 경로가 필요하거나, 해당 클라이언트에서 IPv6를 끄는 의도적인 결정이 필요합니다.

애플리케이션 범위가 세 번째입니다. 규칙은 목적지 기반이므로 그 주소에 연결하는 모든 프로세스가 직접 경로를 사용하며, 의도한 프로세스든 아니든 마찬가지입니다. 반대로 웹사이트는 여러 주소에서 응답할 수 있으므로 하나의 /32를 예외로 둔다고 해서 사이트가 예외가 되지는 않습니다. 실제 요구가 애플리케이션별 라우팅이라면 Community 클라이언트의 경로 테이블은 잘못된 도구입니다.

자신을 속이지 않고 예외 확인하기

브라우저가 아니라 설치된 경로에서 시작하세요. Linux에서는 특정 주소에 어떤 경로와 다음 홉을 사용할지 커널에 물어보고, Windows에서는 해당 /32의 경로 테이블을 읽습니다. 게이트웨이가 터널이 아니라 물리적인 것인지 확인하세요. 항목이 없으면 프로필이 적용되지 않았거나 클라이언트에 경로를 바꿀 권한이 없었던 것입니다.

그다음 두 목적지를 시험하세요. 예외 주소로의 요청은 물리 인터페이스로 나가야 하고, 대조용 내부 주소로의 요청은 여전히 터널을 사용해야 합니다. 예외 주소만 시험해서는 터널의 나머지에 대해 아무것도 증명하지 못하며, 공개 웹사이트를 시험하면 그 사이트가 해석된 주소를 시험하게 되는데, 그것이 규칙의 주소가 아닐 수 있습니다.

마지막으로 경로를 무시할 수 있는 제어를 확인하세요. 클라이언트 측 kill switch나 Windows의 block-outside-dns 설정은 직접 트래픽을 금지할 수 있으며, 이는 경로가 올바른데도 연결이 실패하는 형태로 나타납니다. 예외가 작동하는 것처럼 보이게 하려고 그 제어를 끄지 마세요; 정책이 직접 경로를 금지한다면 예외는 VPN 서비스 소유자에게 설계 문제입니다.

VPN 이전의 게이트웨이와 사용 가능한 경로는 프로필이 아니라 그 순간의 속성이므로, 다시 연결하거나 네트워크를 바꾼 뒤 다시 확인하세요.