route-nopull 만으로는 파일 서버에 접근할 수 없는 이유

파일 서버는 잘 열리는데 옆 창의 화상 통화가 끊기기 시작합니다. 느린 것도 없고 MTU가 잘못된 것도 아닙니다: 클라이언트가 서버가 준 경로 목록을 받아들였기 때문에 이제 모든 패킷이 사무실 방화벽으로 나갑니다. 해결책은 또 하나의 튜닝 플래그가 아니라 클라이언트의 경로 테이블을 누가 소유하는지에 대한 결정입니다. 그 결정은 한 곳에 속하며, 아래의 실패 방식이 실제로 어느 쪽을 골랐는지 알려줍니다.

경로 테이블의 소유자를 정하십시오

소유자는 세 가지가 가능합니다. 서버가 경로와 기본 게이트웨이를 푸시하면 클라이언트는 시키는 대로 설치하고 전체 터널이 됩니다. 클라이언트 프로필이 푸시를 버리고 자체 경로 줄을 들고 있으면 소유권을 가져갈 수 있습니다. 데스크톱 연결 관리자도 자체 경로 및 기본 경로 속성을 통해 결정을 소유할 수 있습니다.

각 선택은 서로 다른 방식으로 실패하기 때문에 프로필을 편집하기 전에 표를 읽어 볼 가치가 있습니다. 증상과 일치하는 행이 실제로 가지고 있는 소유자입니다.

하나를 골라 적어 두십시오. 둘을 섞으면 기본 경로가 자체 문서와 모순되는 호스트가 남고, 다음 엔지니어는 어느 계층이 이겼는지 알 수 없습니다. 진 쪽을 명시적으로 삭제하십시오.

route-nopull은 푸시를 걸러낼 뿐 경로를 추가하지 않습니다

route-nopull은 클라이언트 프로필에 들어가며, 그 파일에서의 순서는 무관합니다: 서버에서 오는 값만 버리기 때문입니다. 푸시된 경로를 버리며, 푸시된 기본 경로도 포함하지만, 터널은 여전히 정상적으로 올라옵니다.

사람들이 놓치는 결과는 푸시된 DHCP 옵션도 함께 사라진다는 것입니다. 서버가 보낸 DNS 설정도 버려지므로, 터널이 건강하고 서버에 주소로 접근할 수 있어도 내부 이름이 확인되지 않습니다.

그래서 직접 추가하지 않으면 사무실 프리픽스로 가는 경로가 없는 터널이 남습니다: 같은 프로필에 route-nopull 뒤에 route 10.30.0.0 255.255.0.0을 두십시오. 그 줄은 주소와 마스크를 담고, 다음 홉을 지정하지는 않습니다.

다른 형태는 게이트웨이 토큰을 덧붙입니다: route 10.30.0.0 255.255.0.0 vpn_gateway은 항목을 이름으로 터널에 향하게 합니다. 가져오기 도구가 이 변형을 변환하는지는 서로 다르므로, 커널 테이블에 항목이 없으면 저장된 연결을 살펴보십시오.

ping이 아니라 경로 조회로 확인하십시오

ping은 무언가가 응답했다고 알려줍니다. 경로 조회는 커널이 어느 인터페이스를 고를지 알려주며, 그것이 실제로 던진 질문입니다. 네 개의 짧은 명령으로 빠진 경로와 잘못된 장치를 가리키는 경로를 구분할 수 있습니다.

ip route show dev tun0로 터널이 무엇을 설치했는지 읽어 보십시오. 출력이 전혀 없다는 것은 경로가 없다는 뜻이며, 이는 동작하는 분할 터널이 아니고, 명시적 줄 없이 필터를 추가했을 때의 흔한 결과입니다.

그다음 ip route get 10.30.5.7으로 사무실 주소 하나를, ip route get 1.1.1.1로 일반 인터넷 주소 하나를 확인하십시오: 두 번째는 물리 인터페이스를 가리켜야 합니다. 터널을 가리킨다면 푸시가 전혀 걸러지지 않은 것입니다.

마지막으로 ip rule을 읽어 보십시오: 이전 시도가 남긴 정책 규칙이 방금 고친 테이블을 덮어쓸 수 있기 때문입니다. 위에 낡은 규칙이 얹힌 올바른 프로필은 망가진 프로필과 똑같아 보입니다. 다음 규칙을 추가하기 전에 지난번에 추가한 규칙을 삭제하십시오.

겹치는 서브넷은 망가진 터널처럼 보입니다

클라이언트 입장에서는 두 사설 범위가 같을 수 있고, 바로 그 지점에서 분할 터널이 자기가 일으키지 않은 일로 비난받습니다. 사무실이 집 라우터가 쓰는 것과 같은 프리픽스를 나눠 주면 터널 경로가 라우터를 덮어 집 네트워크가 사라진 것처럼 보입니다.

무엇이든 바꾸기 전에 단순한 주소 목록을 써서 자기 인터페이스의 주소와 프로필이 설치하는 경로를 비교하십시오. 겹침은 실제이며 어떤 프로필 옵션도 그것을 해결하지 못합니다. 고칠 수 있는 것은 이름 붙이기이며, 다음 사람이 하나가 아니라 두 범위를 보게 하는 것입니다.

정직한 수정은 한쪽의 번호를 다시 매기거나 사무실에서 주소를 변환하는 것입니다. 단일 호스트 경로를 라우터에 고정하는 것은 라우터 주소가 바뀔 때까지 작동하고, 그다음에는 첫 번째 수수께끼 위에 두 번째가 얹힙니다.

결정이 재연결 후에도 살아남게 하십시오

손으로 입력한 항목은 재연결을 견디지 못하고, 연결 관리자는 프로필이 시작될 때마다 테이블을 다시 만듭니다. 결정을 연결이 만들어지는 곳, 즉 프로필이나 관리자의 저장된 설정에 두십시오. 그런 다음 통화 중에 동작을 알아내는 대신 한 번 일부러 연결을 다시 시작하십시오. 다음 재연결까지만 작동하는 프로필은 끝난 것이 아닙니다.

세 경로를 동시에 연습하십시오: 리터럴 주소로 사무실 호스트, 이름으로 같은 호스트, 그리고 일반 공개 사이트입니다. 가운데 것은 푸시된 DNS 옵션을 버린 뒤 구성한 이름 서비스에 달려 있고, 조용히 실패하는 것이 바로 그것입니다.