OpenVPN route-nopull이 실제로 서버가 밀어내는 것을 막는 범위

터널이 기본 경로를 삼키지 않도록 클라이언트 프로필에 route-nopull을 넣었는데, 이제 사무실 서브넷에 닿지 않으면서 클라이언트는 여전히 연결됐다고 표시합니다. 두 관찰 모두 사실이고 아무것도 실패하지 않았습니다. 이 플래그는 서버가 밀어내는 경로와 DHCP 항목을 건너뛰라고 클라이언트에 지시하며, 추가할 때 대부분이 기대하는 것보다 좁은 지시입니다. 남는 것은 어느 목적지가 그것을 써야 하는지에 대한 의견이 없는, 동작하는 터널입니다.

그 간극이 바로 이 글의 주제인 전체 결정입니다. 서버가 네트워크를 설명하든 클라이언트가 설명하든, 이 플래그는 그 일을 당신 대신 아무것도 하지 않은 채 클라이언트에게 넘깁니다.

연결 시점에 플래그가 끄는 것

끌어오는 OpenVPN 클라이언트는 보통 인증 후 서버에서 경로, 기본 게이트웨이 재지정, DNS 서버, 그리고 몇 가지 조정 지시문의 묶음을 받습니다. route-nopull이 적용된 상태에서도 클라이언트는 세션을 계속 받고, 인증서를 계속 검증하며, 암호와 keepalive를 계속 협상하고, 인터페이스를 계속 올립니다. 버리는 것은 밀어낸 route 줄과 밀어낸 dhcp-option 줄의 적용이며 DNS도 포함됩니다.

혼란은 죽은 애플리케이션 옆의 초록색 표시에서 옵니다. 터널은 존재하지만 목적지를 그 터널로 매핑하는 것은 없으며, 클라이언트 상태 패널의 어느 것도 «연결되어 라우팅 중»과 «연결되어 있으나 무효»를 구별하지 못합니다. 터널 입장에서는 둘 다 같은 상태이기 때문입니다.

살아 있는 터널이 그래도 아무것도 라우팅하지 못하는 이유

인터페이스는 자기 주소와 함께 나타나고, 점대점 링크에서는 종종 피어로 가는 호스트 경로보다 더 구체적인 것이 없습니다. 사설 서브넷은 올바른 프리픽스로 그 인터페이스를 가리키는 경로가 있어야 도달 가능해지며, 밀어내기가 꺼져 있으면 그 경로는 결코 오지 않습니다. 내려받은 프로필도 서버가 바로 이 정보를 제공한다고 가정하고 작성되었기 때문에 보통 도움이 되지 않습니다. 그래서 인터페이스는 건강해 보이는데 서브넷은 어두운 채로 남습니다.

따라서 프로필을 읽는 것은 거의 아무것도 증명하지 못하므로, 대신 연결된 머신에서 실행 중인 상태를 읽으세요.

ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10

두 번째 명령에 서브넷 경로가 없는 주소가 이 문제의 서명입니다. 세 번째 명령은 사용되기를 기대한 목록이 아니라 특정 목적지에 대해 커널이 고를 인터페이스를 보고하기 때문에 사용자가 실제로 신경 쓰는 질문에 답합니다. 그것이 물리 링크를 통해 답한다면 터널은 경로에 전혀 없습니다.

이름 해석 실패는 별개의 이유가 아니라 관련된 이유 때문입니다. 밀어낸 dhcp-option DNS 항목은 같은 플래그로 건너뛰므로 내부 호스트 조회는 로컬 네트워크가 제공한 리졸버로 갑니다. 그 리졸버에는 사무실용 존이 없으므로 조회가 실패하거나 공개 응답을 돌려주고, 클라이언트 설정 문제가 서버 문제처럼 보입니다. 이름보다 주소를 먼저 시험하는 것이 둘을 갈라놓습니다.

플래그와 프리픽스 필터 사이의 선택

두 옵션은 같은 불만의 다른 형태를 해결하며, 잘못된 선택이 «연결되었지만 쓸모없는» 상태를 만듭니다. 하나는 밀어낸 정책을 통째로 바꾸고, 다른 하나는 프리픽스 단위로 편집합니다. 표가 짧은 버전을 보여주고, 그 뒤 문단이 사람들을 놀라게 하는 부분을 다룹니다.

pull-filter은 세 개의 동사를 가진 프리픽스 매처라서 줄 계열을 받아들일 수도, 조용히 무시할 수도, 프리픽스가 나타나면 연결 자체를 거부할 수도 있으며, 알아 둘 가치가 있는 것은 마지막 동작입니다. 거부 규칙은 정책 불일치를 조용한 누락이 아니라 실패한 핸드셰이크로 바꿉니다. OpenVPN 2.6 매뉴얼에 허용되는 프리픽스와 각 동사의 정확한 의미가 나옵니다.

흔한 중간 경로는 redirect-gateway만 거부하고 사무실 경로와 DNS가 의도대로 도착하게 두는 것입니다. 서버가 당신보다 잘 이해하는 부분에서는 밀어내기를 계속 동작시키면서, 기본 경로를 가로챌 그 한 줄만 막습니다.

경로와 리졸버를 직접 추가하기

플래그를 유지한다면 프로필이 서버가 말했을 내용을 말해야 합니다. 클라이언트 측 route 지시문은 연결이 맺어진 뒤 적용되므로 플래그에 막히지 않고 나란히 동작합니다. 대화형 명령줄이 아니라 프로필에 넣지 않으면 다음 재연결에서 동작 상태가 재현되지 않습니다.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

DNS 줄은 클라이언트 측 지시문이지만 일부 클라이언트는 플랫폼의 DNS 통합을 통해서만 적용하며 링크가 바뀌면 덮어쓸 수 있는 곤란한 위치에 있고, systemd 호스트에서는 클라이언트가 우선순위 경쟁에서 이기기를 바라는 것보다 터널 인터페이스에 리졸버를 직접 설정하는 편이 예측 가능합니다.

resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.com

라우팅 도메인은 주소만큼 중요합니다. 이것이 없으면 공개 이름 조회도 내부 리졸버로 보내질 수 있고, 재귀를 거부하는 내부 리졸버는 사설 존을 동작시킨 채 브라우징을 깨뜨립니다. 이것이 있으면 그 접미사 아래의 이름만 터널 리졸버로 라우팅되고 나머지는 물리 링크를 따릅니다.

결과 확인: 주소, 이름, 외부 경로

세 가지 시험이 가능한 실패를 갈라놓습니다. 먼저 IP로 사설 주소를 가져오고, 다음으로 이름으로 같은 호스트를, 마지막으로 평범한 공개 사이트를 가져옵니다. IP가 되고 이름이 실패하면 리졸버, IP가 실패하고 이름이 되면 라우팅, 둘 다 실패하면 보통 터널이 경로에 없습니다.

그다음 안이 아니라 밖을 보세요. 터널 끝점 자체의 경로가 변화를 견뎌야 하고, 어떤 차단 실패도 끝점을 잡지 않은 채 터널로 한정되어야 합니다. 터널이 끊긴 뒤에도 브라우징을 계속하는 클라이언트는 라우팅이 아니라 정책 문제이며, 위의 세 시험 어디에도 나타나지 않습니다.

최종 목록을, 경로, 리졸버, 도메인, 그리고 각각이 존재하는 이유와 함께 프로필 문서에 적으세요. 같은 표를 재현하는 재연결만이 로컬 정책이 완전하다는 유일한 증거입니다. 터널이 올라가 있고 세 시험이 모두 통과하는데도 애플리케이션이 실패한다면, 다음에 볼 곳은 이미 검증된 인증서가 아니라 «연결되었지만 오프라인» 부류의 문제입니다.