지사 경로를 추가하면 작동하지만, 펌웨어 업데이트나 웹 UI에서의 저장이 그것을 제거합니다. 그 순간 두 가지 수정은 똑같이 합리적으로 보입니다: 경로를 어플라이언스의 지원되는 설정 소스에 넣거나, 시작 스크립트에서 생성 파일에 추가하는 것입니다. 일주일 동안은 같게 동작하고 두 번째 업그레이드에서 갈라집니다. 이 글은 각각이 실제로 무엇을 소유하는지 비교합니다.

두 후보는 서로 다른 것을 소유한다

지원되는 설정 소스는 어플라이언스가 입력으로 취급하는 모든 것입니다: GUI 필드, 가져온 프로필, 클라이언트별 문서화된 디렉터리, 관리 패키지가 읽는 설정 데이터베이스입니다. 생성된 server.conf 은 출력입니다. 출력 편집은 생성기가 다시 실행될 때까지 작동하며, 그것은 저장할 때, 재부팅할 때, 업그레이드할 때 일어납니다.

스크립트 접근 방식은 생성기가 끝난 뒤 그 출력을 패치합니다. 실험실에서는 정당한 기법이지만, 지사 사무실에서는 경로를 문서화된 필드가 아니라 텍스트 일치에 의존하게 만들기 때문에 잘못된 기본값입니다.

QuestionSupported config sourcePost-generation script
Survives a GUI saveYesOnly if the save does not regenerate the file
Survives a package upgradeUsually, when the field is documentedNo guarantee; the wrapper can be replaced
Supportable by the vendorYesNo
Obvious to the next adminYes, it is in the UINo, it lives in a wrapper

어플라이언스가 무엇을 언제 다시 생성하는가

관리 패키지는 보통 설정을 데이터베이스나 템플릿 집합에 보관하고 시작할 때 데몬 구성을 렌더링합니다. 웹 UI에서의 저장은 한 줄을 패치하는 대신 파일 전체를 다시 쓰는 경우가 많습니다. 변경 사항이 그 파일에 있었다면 이제 사라졌고, 어플라이언스 관점에서는 아무것도 잃지 않았기 때문에 아무것도 경고를 기록하지 않습니다.

시작 래퍼에는 두 번째 실패 모드가 있습니다. 특정 간격을 가진 지시문에 대한 grep 은 템플릿 변경 후 일치를 멈추고, 스크립트는 조용히 아무것도 하지 않습니다. 더 나쁘게는 펌웨어 업데이트가 래퍼를 새 버전으로 교체하면서 패치를 함께 가져갈 수 있습니다. 그러면 한 해 동안 존재했던 경로가 아무도 라우팅과 연결하지 않은 유지보수 중에 사라집니다.

지원되는 소유자가 표현해야 하는 것

지사 접두사에는 하나가 아니라 세 가지 진술이 필요합니다. 클라이언트는 경로를 배워야 하고, 서버는 어느 인증된 클라이언트가 접두사를 소유하는지 알아야 하며, 지사 측은 부여받은 터널 주소로 트래픽을 돌려보내야 합니다. OpenVPN 용어로는 푸시된 route, 클라이언트에 묶인 일치하는 iroute, 그리고 반대편의 반환 경로를 뜻합니다.

여기서 어플라이언스 UI가 오해를 부릅니다. “클라이언트가 서버 LAN에 접근하도록 허용”이라는 체크박스는 서버 자체 네트워크로 향하는 트래픽을 설명합니다. 귀하의 지사는 반대 방향입니다: 한 클라이언트 뒤의 네트워크이며 서버 측에서 접근할 수 있습니다. 같은 레이블이 그에 대한 지원을 의미하지는 않으며, 파일의 유효한 지시문이 패키지가 그것을 보존하리라는 약속은 아닙니다.

지원되는 제어가 없을 때

때로 설치된 릴리스가 피어별 경로를 정말로 표현할 수 없습니다. 그때 정직한 선택은 직접 제어하는 다른 게이트웨이거나 양쪽 끝에서 지원되는 사이트 간 모드입니다. 양쪽 끝이 그것을 말해야 합니다. 사이트 간이라고 적힌 제품 페이지가 임의의 OpenVPN 프로필을 다른 프로토콜의 터널과 호환되게 만들지는 않으며, 그 짝을 강제하면 보통 상태 페이지에서는 멀쩡해 보이는 반쯤 연결된 터널이 생깁니다.

네트워크를 물려받을 사람에게 한 문장으로 설명할 수 있는 선택을 고르십시오. 답에 스크립트 경로와 텍스트 패턴을 언급해야 한다면 설계는 이미 취약합니다.

의도를 감사 가능하게 만들기

계약을 어플라이언스 외부에 기록하십시오: 유효한 클라이언트 신원, 접두사, 반환 게이트웨이, 그리고 각각을 제공하는 지원되는 필드입니다. 지원되는 메커니즘으로 구성을 내보내 재구축에 참조가 있게 하고, 변경 후에만이 아니라 재연결, 재시작, 업그레이드 후에 서비스를 검증하십시오.

무언가 깨졌을 때는 설명되지 않는 줄을 복원하고 기대하는 대신, 생성된 결과를 그 기록과 비교하십시오.OpenVPN 2.6 참조 는 UI와 논쟁하기 전에 route 와 iroute 가 어떻게 상호작용하는지 확인할 장소입니다.

다음 변경을 위한 체크리스트: 소유자를 지목하고, 세 부분 계약을 진술하고, 의도를 내보내고, 편집 후가 아니라 어플라이언스 자체의 수명 주기 이벤트 후에 다시 테스트하십시오.

관련 글