route-gateway는 redirect-gateway가 아니다: 실제로 무엇이 바뀌는가
이 옵션은 OpenVPN이 설치하는 경로에 다음 홉만 제공합니다. 삭제해도 푸시된 전체 터널이 꺼지지 않으며, 수정은 리디렉션에 있습니다.
터널이 올라오고 사설 서브넷이 응답하는데, 누군가 프로필에서 게이트웨이 줄을 지웠는데도 일반 브라우징은 여전히 VPN 속으로 사라집니다. 그 조합이 바로 잘못된 지시어를 편집했다는 지문입니다. 삭제된 것은 클라이언트가 설치하는 경로에 다음 홉을 주고 있었지만, 트래픽을 계속 잡아낸 것은 다른 곳에서 와서 서버가 푸시한 것입니다. 커버리지와 다음 홉은 별개의 작업이고, 둘 중 하나만이 공용 목적지가 터널을 쓰는지를 결정합니다.
삭제한 줄은 정책 스위치가 아니라 다음 홉이었습니다
클라이언트가 설치하는 모든 경로에는 가리킬 게이트웨이 주소가 필요하고, 경로 자체가 주소를 지정하지 않을 때 게이트웨이 지시어가 그 주소의 출처입니다. 그것을 지우면 그 경로들은 매달릴 곳이 없어서 설치되지 않거나 아무 데도 이어지지 않는 길로 떨어집니다. 사설 서브넷은 바로 그런 경로가 나르던 것입니다.
한편 살아남은 동작에는 플래그에 따라 일반 아웃바운드 트래픽을 터널로 옮기는 푸시된 블록의 리디렉션 옵션이라는 다른 작성자가 있습니다. 게이트웨이를 삭제해도 그것을 끄지도 약화시키지도 않습니다. 결과는 두 상태 중 최악으로, 공용 트래픽은 여전히 잡히고 터널을 정당화했던 사설 목적지는 이제 도달할 수 없습니다. 그래서 같은 취지로 한 두 번째 편집도 아무것도 바꾸지 않습니다.
네 개의 레버, 네 개의 다른 일
이 논의에서 네 개의 지시어가 서로 바꿔 인용되는데, 그중 커버리지를 지배하는 것은 하나뿐이며, 즉 어떤 목적지가 터널을 지나는지입니다. 두 번째는 경로가 쓰는 다음 홉을 정하고, 세 번째는 단일 프리픽스를 설치하며, 네 번째는 서버가 푸시한 모든 것을 버리는데, 배포에 필요한 사설 경로까지 포함해서입니다. 표가 이름이 아니라 관리자가 바꾸려는 것 기준으로 정렬하는 이유는 혼란을 일으키는 것이 바로 이름이기 때문입니다. 네 가지 별개의 결정으로 다루고 정말 되돌리고 싶은 것을 고르세요.
실제로는 네 가지가 흔히 하나의 푸시된 블록에 줄줄이 도착해서 한 설정의 일부처럼 보입니다. 그렇지 않으며, OpenVPN 참조 문서가 그것들을 별개의 메커니즘으로 기록하는 이유도 바로 그것입니다. 어떤 결정을 되돌리는지 파악하는 것이 일이고, 편집은 한 줄입니다.
| What you are trying to change | Directive that decides it | What it leaves alone |
|---|---|---|
| Which destinations use the tunnel | redirect-gateway | Per-prefix routes and resolver choice |
| The next hop a pushed route points at | route-gateway | Coverage of public destinations |
| One reachable prefix | route | Every other destination, default path included |
| All pushed routing and DNS at once | route-nopull | Nothing, which is the problem |
푸시된 줄을 필터링하고 다음 홉은 유지
불만인 커버리지가 푸시된 옵션으로 온다면, 좁은 대응은 그 옵션을 이름으로 무시하고 푸시된 블록의 나머지를 그대로 두는 것입니다. 필터로 쓰면 아래 줄처럼 되고, 위치는 영향을 받는 클라이언트의 프로필이지 서버 구성이 아닙니다.
pull-filter ignore "redirect-gateway"좁음이 핵심입니다. 필터는 텍스트 프리픽스를 비교하므로 더 짧은 패턴은 다음 홉 지시어에도 일치하고, 그렇게 사설 경로가 의존하는 정보를 정확히 벗겨 내며 원래 실수를 새 옷으로 반복합니다. 필터는 푸시된 옵션에만 작용하므로 로컬에 쓰였거나 네트워크 관리자가 강제한 동등한 줄은 절대 건드리지 않습니다. 살아 있는 세션은 서버가 푸시한 것을 다시 평가하지 않으므로 그런 다음 다시 연결하세요.
표가 아니라 조회를 읽으세요
프로필을 다시 로드한 뒤 커널에, 사설 프리픽스 안과 공용 인터넷이라는 두 목적지가 실제로 어디로 갈지 물으세요. 메인 테이블의 전체 덤프는 읽기 어렵고 잘못 읽기 쉬운데, 경로가 존재해도 더 구체적인 일치에 질 수 있기 때문입니다. 정책 기반 라우팅에서는 규칙, 테이블, 소스 주소도 점검에 포함됩니다.
ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule showdef1 변형은 오래된 기본 항목을 보이게 두면서 반쪽 기본값 한 쌍이 조회를 이기는 덕에 알아 둘 가치가 있습니다. 따라서 출력의 0.0.0.0/0 줄만으로는 아무것도 증명하지 못합니다. 조회는 목록이 답하는 것처럼 보이는 질문에 답합니다.
DNS, IPv6, 사설 경로는 여전히 동작해야 합니다
IPv4 리디렉션 하나를 거부한다고 리졸버에 대해 말할 수 있는 것은 없으므로, 푸시된 DNS 옵션은 경로가 올바르게 보이는 동안에도 질의를 터널로 계속 보낼 수 있습니다. IPv6 기본값은 IPv4 점검이 건드리지 않은 주소 계열에 대해 같은 일을 할 수 있습니다. 둘 다 가정이 아니라 명시적 결정이 필요합니다. 그런 다음, 사설 경로를 잃은 분할 터널은 분할 터널이 아니라 망가진 터널이므로 사설 서비스가 여전히 응답하는지 확인하세요.
더 넓은 도구는 경고를 받을 만합니다: route-nopull은 푸시된 모든 경로와 푸시된 DNS 옵션을 버립니다, 이것은 전체 터널을 확실히 멈추고 배포가 의존하는 사설 경로도 똑같이 확실히 부수므로, 하나의 옵션을 겨냥한 이름 필터보다 훨씬 큰 망치입니다. 변경할 때마다 사설 목적지, 공용 목적지, 리졸버를 확인하고, 완료된 핸드셰이크는 핸드셰이크 외에는 아무것도 증명하지 않는다고 여기세요.