bypass-dhcp가 OpenVPN 경로 계획에 실제로 더하는 것

redirect-gateway def1 bypass-dhcp를 가진 프로필은 IPv4 기본 경로 덮어쓰기와 아주 좁은 예외 하나를 결합합니다. 사람들은 마지막 단어만 읽고 모바일 연결의 일반적인 해결책을 기대한 뒤, 이 플래그가 한 번도 지지한 적 없는 DHCP 이론에 오후를 쏟습니다. 각 부분은 한 가지 일만 하고, 예외는 그 명성보다 훨씬 작습니다.

모바일에서만 생기는 실패를 주소 할당 탓으로 돌리기 전에 플래그를 분해해 보세요. 그 문자열의 두 절반은 서로 아무 관계가 없습니다.

두 플래그, 두 개의 무관한 작업

def1을 쓰면 클라이언트는 이미 있는 기본 경로를 바꾸는 대신 IPv4 반쪽 기본 경로 두 개를 추가합니다. 0.0.0.0/1은 주소 공간의 아래 절반을, 128.0.0.0/1은 위 절반을 덮으므로 둘이 합쳐 모든 목적지에 도달하면서도 각각은 0.0.0.0/0보다 더 구체적으로 남습니다. 따라서 원래 기본 경로는 그 조회를 이기지 못한 채 테이블에 남고, 이는 클라이언트가 명시적으로 라우팅하는 모든 것에 대해 예전 게이트웨이를 도달 가능하게 유지합니다. 또한 겹치는 기본 경로 두 개를 테이블에 남기므로, 경로 덤프가 프로필이 암시하는 것보다 더 이상해 보일 수 있습니다.

bypass-dhcp는 별개이며 기본 경로를 전혀 건드리지 않습니다. OpenVPN 2.6 설명서는 이것을 로컬 서브넷에 없는 DHCP 서버로 가는 직접 경로를 추가해 임대 트래픽이 터널 밖으로 나가게 하는 것으로 설명하고, 이 동작이 Windows 클라이언트에 구현되어 있으며 다른 곳에서는 제공되지 않을 수 있다고 적습니다.

존재 이유는 기계적입니다. 반쪽 기본 경로가 나가는 트래픽을 붙잡으면, 물리 네트워크의 서버를 향한 DHCP 갱신은 무언가 그 주소를 실제 인터페이스에 고정하지 않는 한 터널 안으로 라우팅됩니다. 플래그가 그것을 고정합니다.

예외가 실제로 미치는 범위

연결에 성공한 뒤의 예시 테이블은 모양을 보여 줍니다. 터널을 지나는 반쪽 기본 경로 두 개와 물리 게이트웨이를 지나는 DHCP 서버용 호스트 경로 하나입니다. 여러분의 주소가 아니라 모양으로 읽으세요.

0.0.0.0/1        via 10.8.0.1      dev tun0
128.0.0.0/1      via 10.8.0.1      dev tun0
192.168.1.1/32   via 192.168.1.254 dev wlan0

그 세 번째 줄은 목적지 하나만 지목합니다. 리졸버 설정도, 로컬 네트워크에 대한 일반 허가도, 서버의 출구 규칙도 아닙니다. 셀룰러 통신망의 휴대폰에는 클라이언트가 이렇게 식별할 수 있는 DHCP 서버가 없을 수 있고, 그래서 플래그는 거기서 아무것도 바꾸지 않습니다.

클라이언트가 실제로 무엇을 설치했는지 확인하세요

프로필에 적힌 옵션, 서버가 제안한 옵션, 연결 소유자가 실제로 적용한 경로를 구분하세요. 지원되지 않는 플래그를 거부한 클라이언트는 나머지 구성을 유지할 수 있으므로 터널은 올라가고 예외만 빠집니다. 파일의 줄이 효력을 냈다고 가정하지 말고 클라이언트 자체 로그와 그 결과 라우팅 테이블을 읽으세요. 이 세 가지는 동시에 참일 수 있고, 패킷이 실제로 어디로 가는지를 바꾸는 것은 마지막 하나뿐입니다.

VPN 끝점으로 가는 경로도 동시에 쓸 수 있게 유지하세요. 이 끝점 예외는 DHCP 예외와 다른 요구 사항이며, 그것이 없으면 터널이 자기를 유지하는 전송을 붙잡을 수 있습니다.

애플리케이션 목적지라면 실패하는 맥락에서 실제 조회를 살펴보세요. 더 구체적인 로컬 경로, 정책 라우팅, 애플리케이션별 제외가 모두 답을 바꾸므로, 반쪽 기본 경로 두 개가 있다는 것이 모든 흐름의 목록은 아닙니다.

나머지 경로는 이 플래그에 없습니다

서버에는 여전히 클라이언트의 인터넷 트래픽을 전달할 권한과 그것을 되돌려 보낼 출구 구성이 필요합니다. 클라이언트 쪽 경로는 서버에 없는 전달이나 출발지 변환을 만들어 내지 않으며, 어떤 플래그도 작동하는 귀환 경로를 대신하지 못합니다.

이름 해석과 IPv6는 각각 고유한 정책이 필요합니다. IPv4 덮어쓰기는 리졸버를 터널 쪽 서버로 돌리지도, IPv6 커버리지를 세우지도 않으며, v4만 리디렉션하는 클라이언트는 v6 경로를 그대로 둡니다.

프로필과 목적지를 고정한 채 승인된 무해한 요청 하나를 정상 경로와 실패 경로에서 비교하세요. 차이가 이름 해석, 터널 수립, 경로 선택, 전달된 트래픽 중 어디에 있는지 기록하고 그 답을 프로필과 함께 보관하세요. 그 기록이 다음 사람이 닿을 수 없는 문제를 DHCP 탓으로 돌리지 않게 막아 줍니다.