공유 pppd 옵션 파일이 다른 VPN을 망가뜨리는 이유

고집스러운 PPTP 프로필을 연결하려고 한 줄을 추가했는데, 일주일 뒤에는 몇 달 동안 잘 작동하던 L2TP 클라이언트가 멈춥니다. 당연히 두 프로토콜이 이제 충돌한다고 읽게 됩니다. 하지만 더 흔한 경우는 두 클라이언트가 모두 pppd를 실행하고, 둘 다 같은 기본값을 읽으며, 추가한 그 줄이 애초에 고치려던 프로필에 한정되지 않았다는 것입니다. 공유 옵션 파일이 바로 그 결합 지점이고, 프로토콜은 잘못이 없습니다.

클라이언트가 시작할 때 물려받는 것

PPP 기반 클라이언트가 명령줄을 처음부터 만드는 경우는 드뭅니다. 클라이언트는 pppd를 실행하고, pppd는 시스템 기본값을 읽은 다음 사용자 파일이나 터미널 파일, 그리고 클라이언트가 넘긴 인자를 읽습니다. 클라이언트가 피어 파일을 지정할 수도 있습니다. 이 각 계층은 플러그인, 인증 방식, 라우트 지시자를 담을 수 있고, 보호된 옵션을 먼저 설정한 계층이 이후 변경을 잠글 수 있습니다.

그래서 유용한 질문은 어느 VPN이 고장났느냐가 아니라 어느 계층이 그 설정을 공급했느냐입니다. 스스로 인자를 생성하는 클라이언트는 자급자족처럼 보이지만 시스템 파일이 가진 모든 것을 그대로 물려받습니다.

바꾸기 전에 그 줄의 출처를 밝히세요

먼저 연결이 살아 있는 동안 실행 중인 프로세스를 보세요. 명령줄에는 어떤 파일이 명시적으로 전달되었는지 나오고, 거기 없는 것은 기본 경로에서 온 것입니다.

ps -o pid=,args= -C pppd

인자 목록에 피어 이름이 있으면 그 파일을 읽으세요. 없으면 찾고 있는 설정은 공유 경로에 있습니다. pppd 설명서에는 그 파일들을 읽는 순서와 일반 사용자가 재정의할 수 없는 옵션이 나열되어 있습니다. 그래서 나중에 쓴 줄이 아무 효과도 없는 경우가 생깁니다. 플러그인 경로 같은 보호된 옵션은 나중의 사용자 수준 줄로 바꿀 수 없으므로, 잘못된 파일을 편집하면 눈에 보이는 변화가 없습니다.

모든 클라이언트를 따라다니는 플러그인 줄

시스템 파일에 로드된 플러그인은 최악입니다. 사용자가 어느 버튼을 눌렀든 새 PPP 프로세스가 무엇을 로드하려는지를 바꾸기 때문입니다. L2TP 플러그인이 전형적인 예입니다. 한 프로필에는 맞지만, 같은 기본값에서 시작하는 PPTP 프로필에는 의미가 없거나 해롭습니다.

그 줄을 클라이언트가 선택하는 피어 파일로 옮기거나, 클라이언트가 지원한다면 연결별 설정으로 옮기세요. 그냥 삭제하면 두 번째 클라이언트는 고쳐지고 첫 번째는 깨지는데, 문제가 팀 사이를 옮겨 다니는 방식이 바로 이것입니다.

옮긴 뒤 각 클라이언트를 확인하세요

같은 머신에서 두 연결을 차례로 테스트하고, 성공 대화상자가 아니라 협상된 옵션을 읽으세요. 아래 덤프는 pppd가 실제로 조립한 옵션 집합을 출력하며, 그것이 유일하게 중요한 목록입니다.

sudo pppd call office debug dump

두 번째 클라이언트에 대해서도 반복하고 두 출력을 비교하세요. 옮긴 옵션은 정확히 한쪽에만 나타나야 합니다. 양쪽 모두에 나타나면 클라이언트가 그 옵션을 다시 생성하는 것이므로, 수정은 공유 파일이 아니라 그 프로필에 속합니다. 이제 그 설정이 어디에 있는지 연결 옆에 기록해 두세요. 다음 사람이 그것을 다시 깨뜨려 결합을 재발견하지 않도록.