OpenVPN이 계속 오래된 경로를 밀어내나요? 실제로 무엇을 불러왔는지 확인하세요
서버가 편집 내용을 읽지 않았거나, 클라이언트가 받은 것을 설치하지 않은 것입니다. 실행 중인 프로세스, 밀어낸 목록, 돌아오는 경로를 비교하세요.
경로를 추가하고 서비스를 다시 시작하고 다시 연결해도 클라이언트의 표는 이전과 똑같아 보입니다. 서버가 편집 내용을 불러오지 않았거나 클라이언트가 받은 것을 설치하지 않은, 두 가지 다른 일이 사실일 수 있습니다. 증상 말고는 공통점이 없으니 첫 단계는 둘 중 어느 쪽인지 알아내는 것입니다.
아래 비교는 어떤 파일이 효력을 가지는지 아는 유일한 주체가 프로세스이기 때문에 프로세스에서 바깥으로 진행됩니다.
편집한 파일과 프로세스가 읽는 파일
unit 과 그것이 만든 명령줄부터 시작하세요. systemd 호스트에서 systemctl cat openvpn@server 은 ExecStart 줄을 출력하고, 인스턴스 unit 은 보통 인스턴스 이름에서 설정 경로를 이끌어 내므로 openvpn@office 로 시작한 데몬은 openvpn@server 로 시작한 것과 다른 파일을 읽습니다. 이것을 실행 중인 프로세스의 argv 와 비교하세요. 구성 관리 도구는 변경을 잃는 또 다른 길을 더하는데, 올바른 파일을 unit 이 한 번도 언급하지 않은 위치에 쓸 수 있어서 성공한 배포가 아무 일도 하지 않은 것처럼 보입니다.
파일이 프로세스 시작 시각보다 새롭다면 프로세스는 그 파일을 읽을 수 없었으므로 타임스탬프가 이를 빠르게 판가름합니다. 라우터 펌웨어는 세 번째 경우를 더하는데, 많은 모델이 설정을 플래시에 보관하고 부팅 중에 구성을 다시 만들기 때문에 디스크의 파일 편집은 완전히 잘못된 계층이 됩니다.
서버가 밀어내는 것과 클라이언트가 설치하는 것
밀어낸 경로는 두 개의 필터를 통과해야 합니다. 서버에서는 주석 처리된 블록이나 이름이 맞지 않는 클라이언트 전용 파일이 아니라 불러온 구성에 있어야 합니다. 클라이언트에서는 pull 이 켜져 있어야 하고 어떤 pull-filter 도 그 옵션을 버리지 않아야 합니다. verbosity 4 로 연결해 클라이언트가 보고하는 밀어낸 옵션을 읽으면, 경로가 그 목록에 있을 때 서버는 할 일을 했고 설치하지 않는 쪽은 클라이언트의 선택입니다.
클라이언트 전용 파일은 흔한 혼란의 원인입니다. 인증서의 common name 으로 이름 붙인 파일은 그 클라이언트에게만 옵션을 밀어내고, 한 글자만 어긋나도 밀어내기가 조용히 멈추며 어느 쪽에도 오류가 나지 않습니다. 서버는 연결할 때 본 common name 을 기록하므로, 그 값을 클라이언트 이름이라고 생각하는 것과 비교하지 말고 파일 이름과 비교하세요.
밀어낸 접두사와 돌아오는 경로는 다른 문제입니다
redirect-gateway 을 일부러 무시해 로컬 인터넷 경로를 유지하는 클라이언트는 두 번째의 무관한 틈을 만듭니다. 서버의 프로브는 터널 주소에 도달하지만 응답이 끝내 오지 않는 것은, 서버의 터널 IP 로 보낸 응답이 클라이언트의 평범한 기본 게이트웨이로 라우팅되기 때문입니다. 여기서 문제는 밀어낸 서브넷 경로가 아니라, 서버의 터널 네트워크로 가는 트래픽을 터널 장치로 되돌려 보내는 경로가 빠져 있다는 점입니다.
클라이언트에 그 경로를 추가하면 서버가 시작한 프로브에 대한 응답이 고쳐집니다. 밀어낸 서브넷 경로를 대신하지 않으며 그 반대도 마찬가지인데, 둘은 반대 방향의 이동을 설명하기 때문입니다.
양쪽 끝의 표를 비교하세요
변경한 뒤에는 다시 연결해 클라이언트의 표에서 밀어낸 접두사와 터널 장치를 읽으세요. 그다음 클라이언트에서 밀어낸 서브넷의 호스트로, 그 호스트에서 클라이언트로 돌아오는 양방향으로 시험합니다. 경로가 있는데 트래픽이 흐르지 않는다면 반대편이 전달하지 않거나, 방화벽이 흐름을 버리거나, 응답에 돌아갈 길이 없는 세 가지 중 하나입니다.
설정 경로, unit 또는 인스턴스 이름, 시험에 쓴 클라이언트 신원이라는 세 가지 식별자를 함께 남기세요.
이 세 가지가 있으면 다음번에는 재조사가 아니라 오 분 점검으로 끝나고, 터널이 다른 사람의 문제가 되었을 때 동료에게 필요한 것도 바로 이것입니다.
재시작을 견디는 경로 문제는 대개 라우팅 문제조차 아니며, 결함은 계속 들여다보는 표보다 위쪽에 있습니다.