경로를 추가하고 서비스를 다시 시작하고 다시 연결해도 클라이언트의 표는 이전과 똑같아 보입니다. 서버가 편집 내용을 불러오지 않았거나 클라이언트가 받은 것을 설치하지 않은, 두 가지 다른 일이 사실일 수 있습니다. 증상 말고는 공통점이 없으니 첫 단계는 둘 중 어느 쪽인지 알아내는 것입니다.

아래 비교는 어떤 파일이 효력을 가지는지 아는 유일한 주체가 프로세스이기 때문에 프로세스에서 바깥으로 진행됩니다.

편집한 파일과 프로세스가 읽는 파일

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 또는 인스턴스 이름, 시험에 쓴 클라이언트 신원이라는 세 가지 식별자를 함께 남기세요.

이 세 가지가 있으면 다음번에는 재조사가 아니라 오 분 점검으로 끝나고, 터널이 다른 사람의 문제가 되었을 때 동료에게 필요한 것도 바로 이것입니다.

재시작을 견디는 경로 문제는 대개 라우팅 문제조차 아니며, 결함은 계속 들여다보는 표보다 위쪽에 있습니다.

관련 글