OpenVPN 서버 설정을 지사로 복사하면 실패하는 이유

작동하는 서버 설정을 복사하고 주소 몇 개를 바꾼 뒤 지사 프로필이라고 부르면 보통 연결이 됩니다. 그것이 최악의 결과입니다. 지사가 잘못된 역할로 돌아가고, 허브를 떠나서는 안 되는 자료를 노출하며, 아무도 만들었다고 기억하지 못하는 경로 연결을 남기기 때문입니다. 그 연결은 세 가지 문제를 한꺼번에 감추고, 누군가 확인하기 전에 터널이 올라옵니다.

지사를 고유한 정체성과 네트워크 역할을 가진 피어로 다루는 것이 프로필을 올바르게 만듭니다. 해결책은 더 나은 복사본이 아니며, 이 페이지의 나머지는 클라이언트가 실제로 무엇을 가져야 하는지 다룹니다.

하나의 파일처럼 보이는 두 역할

TLS 모드에서 두 피어의 작업은 상호 보완적입니다. 한쪽은 수신하고 서버 인증서와 키를 보관하며 어떤 클라이언트가 연결할 수 있는지 결정합니다. 다른 쪽은 연결을 시작하고 수신자를 검증하며 자신의 정체성을 제시합니다.

서버 파일에는 클라이언트에서 의미가 없는 지시문이 들어 있습니다. 수신할 바인드 주소와 포트, 배포할 주소 풀, 그리고 클라이언트가 받아야 할 설정에 대한 푸시 목록이 흔히 있습니다. 이것을 지사로 복사하면 수신자와 클라이언트를 동시에 하려는 장치가 됩니다.

가장 중요한 부분은 개인 키입니다. 클라이언트는 서버의 개인 키를 절대 지녀서는 안 되며, CA의 서명 키도 필요하지 않습니다. CA 인증서는 공개 신뢰 자료이고, 서명 키는 인증서가 발급되는 곳에 속합니다.

지사 프로필에 반드시 있어야 할 것

지사 프로필에는 원격 엔드포인트와 전송, 신뢰하는 서버 정체성, 지사 자체의 인증서와 키, 그리고 지사가 실제로 필요로 하는 경로와 DNS 설정이 필요합니다. 그 밖에 필수인 것은 없습니다.

지사의 정체성을 사이트마다 분리하십시오. 두 지사가 하나의 인증서를 공유하면 하나를 폐기할 때 다른 하나가 비활성화되고, 허브의 로그가 둘을 구별하지 못합니다. 사이트별 정체성이 감사 추적과 폐기 이야기를 모두 작동하게 합니다.

장비 워크플로에 주의하십시오. pfSense의 Client Export 패키지는 적격한 Remote Access 컨텍스트용 프로필을 만들고, 서버 목록에는 Remote Access 모드로 설정된 서버만 포함됩니다. 다른 모드의 사이트 간 서버는 나타나지 않으며, 그 부재는 정보이지 서버의 비밀을 복사하라는 초대가 아닙니다.

장비가 필요한 프로필을 내보내지 않으면 문서화된 사이트 간 클라이언트 워크플로를 사용하거나 설치된 릴리스의 지원되는 예제에서 프로필을 만드십시오. 서버 백업을 지사로 내보내는 것은 계획이 서버 복원일 때뿐이며, 여기서는 그렇지 않습니다. 백업은 허브의 사설 자료도 지니므로 지사로 옮기는 것은 키 취급에 관한 결정이지 파일 전송이 아닙니다. 허브에 두고 클라이언트 정체성은 인증서가 발급되는 곳에서 만드십시오.

피어와 네트워크의 연결은 별개

성공적으로 연결된 지사 클라이언트도 허브가 이 피어가 그 프리픽스를 소유한다는 것을 알기 전까지는 자기 LAN을 위한 트래픽을 통과시키지 못합니다. 그 연결은 허브에 있고 클라이언트의 정체성에 묶여 있으며, 지사 자체의 원격 네트워크로 가는 경로와는 별개입니다. 그것이 없으면 지사의 호스트는 터널 통계에서는 도달 가능해 보이고 실제로는 도달할 수 없습니다. 연결이 적용되었는지 확인하는 곳은 허브 로그입니다.

허브의 운영 체제에 경로를 추가하는 것은 어느 클라이언트가 프리픽스를 소유하는지 OpenVPN에 알려 주는 것과 같지 않습니다. 클라이언트별 연결이 없으면 패킷은 터널 인터페이스에 도달하고, 어떤 피어도 목적지를 주장하지 않으므로 버려집니다.

지사 쪽에서 해당하는 필요는 도달해야 할 네트워크로 가는 경로와, 트래픽을 지사로 되돌리는 방법을 아는 LAN 라우터입니다. 서버 쪽 소유와 클라이언트 쪽 목적지 경로는 서로 다른 객체이며, 작동하는 터널은 첫 홉만 증명합니다. 둘 다 지사의 인수인계 메모에 적으십시오. 다음 엔지니어는 둘 중 하나만 찾게 됩니다.

지사가 생각하는 그 피어임을 증명하기

트래픽을 검증하기 전에 정체성을 검증하십시오. 허브 로그에는 지사 인증서의 공통 이름이 보여야 하고, 클라이언트가 받은 주소는 의도한 풀이나 고정 할당과 일치해야 합니다. 로그에 다른 이름이 보이면 그 프로필은 다른 사람의 정체성을 지니고 있습니다.

다음으로 지사 호스트에서 허브 쪽 자원으로 요청 하나를 보내 연결을 검증하고, 예상한 출발지 주소로 성공하는지 확인하십시오. 지사가 도달해서는 안 되는 목적지를 시험해 실패하는지 확인하십시오. 우연히 동작하는 관대한 경로는 올바른 정책과 같지 않기 때문입니다.

마지막으로 지사의 정체성을 폐기하고, 허브 자체의 인증서와 다른 사이트가 계속 작동하는 동안 연결이 실패하는지 확인하십시오. 폐기가 허브를 망가뜨린다면 역할과 정체성이 어딘가에서 공유되었다는 뜻이며, 그것이 설계로 되돌려야 할 발견입니다.

완성된 지사는 문서화된 정체성, 클라이언트 전용 프로필, 허브의 피어-네트워크 연결, 시험된 귀환 경로를 갖춘 지사입니다. 서버 파일의 텍스트를 뒤집는다고 해서 그중 어느 것도 얻지 못합니다.