사무실과 VPN 사용자를 위한 단일 CiviCRM URL: 설정 단계

사무실 노트북은 책상에서도, 집에서 VPN을 통해 다시 같은 CiviCRM 북마크를 열 수 있어야 합니다. 사용자와의 접촉에서 살아남는 설계는 하나의 정규 주소, 예를 들어 https://crm.example.org/ 를 정하고 각 위치에서 승인된 네트워크 경로와 그 이름에 유효한 인증서를 갖추는 것입니다. VPN은 원격 클라이언트가 서버에 도달하는 방식을 바꿉니다. 그러나 바꾸는 순간 생성되는 모든 링크, 리디렉션, 통합 콜백이 해결해야 할 두 번째 문제가 되기 때문에 애플리케이션의 정체성을 바꾸어서는 안 됩니다.

경로를 고르기 전에 URL을 고르세요

먼저 CMS가 필요로 하는 경로 구성 요소를 포함해 의도한 주소를 적고 고정점으로 삼습니다. 이 안내서의 나머지는 그것을 건드리지 않고 바뀔 수 있는 구현 세부 사항이며, 여기에는 어느 그룹이 어떤 DNS 응답을 받는지, 어떤 방화벽 규칙이 리스너를 허용하는지, 그리고 트래픽이 터널로 오는지 로컬 스위치 포트로 오는지 가 포함됩니다.

네 가지 값은 하나의 집합으로만 작동하기 때문에 함께 액세스 계획에 기록합니다. 정규 URL. 각 클라이언트 그룹이 그 이름에 대해 받아야 할 응답. 그 응답에 대한 경로와 액세스 규칙. 웹 서버와 인증서가 제공하도록 구성된 호스트 이름. 나중에 무언가 고장 나면 고장 난 요소는 그 네 가지 중 하나이며, 무엇을 변경했는지 알 수 있습니다.

1단계: 두 그룹 모두에서 이름이 올바르게 확인되도록 하세요

두 그룹 모두 실제로 도달할 수 있는 사설 응답을 받아야 하며, 이름이 다르지 않다면 응답이 달라도 정당합니다. LAN 클라이언트는 내부 리졸버로 확인하고, VPN 클라이언트에는 쿼리를 공용 리졸버로 누설해 쓸 수 없는 공용 응답을 받는 대신 같은 영역을 넘겨주는 리졸버 정책이 필요합니다.

가정하지 말고 각 컨텍스트에서 이름을 테스트하고, DNS와 무관하게 한 요청에 대해 주소를 고정하는 curl의 resolve 옵션으로 경로를 테스트하세요:

dig +short crm.example.org
curl -sSI --resolve crm.example.org:443:10.10.5.20 https://crm.example.org/ | head -5

첫 번째 테스트가 클라이언트가 도달할 수 없는 주소를 반환하면 문제는 터널 라우팅이나 분할 터널 목록에 있습니다. 두 번째 테스트가 예상하지 못한 호스트 이름으로의 리디렉션을 반환하면, 애플리케이션 문제이며 어떤 경로 변경으로도 고쳐지지 않으므로 멈추고 Location 헤더를 읽으세요.

2단계: 웹 서버, 인증서, CMS 기본 URL을 맞추세요

리스너는 정규 이름을 제공하도록 구성되어야 하고 인증서는 그 이름을 포함해야 합니다. 원시 주소로 탐색하는 것은 이름 불일치를 일으키고 쿠키 범위를 깨뜨릴 수 있으며 나중에 감사자에게 설명해야 할 경고를 사용자가 그냥 넘기도록 가르치므로 우회책이 아닙니다.

역방향 프록시 뒤에서는 요청이 HTTPS로 도착했음을 애플리케이션이 알 수 있게 하세요. 대부분의 CMS 플랫폼은 감지된 스킴에서 절대 링크를 생성하므로, 원래 스킴을 전달하지 않고 TLS를 종료하는 프록시는 브라우저가 차단할 수 있는 http:// 리소스로 가득한 페이지를 만듭니다. 애플리케이션이 추측하게 두지 말고 신뢰하는 프록시와 전달 헤더를 명시적으로 구성하세요.

그런 다음 CMS와 CiviCRM의 기본 URL을 맞춥니다. CiviCRM은 결정된 기본 URL을 유지하며, CiviCRM 설치 문제 해결 안내서에 문서화된 관리 작업인 Cleanup Caches and Update Paths를 통해 이를 다시 계산하는 지원되는 방법을 제공합니다. 정규 이름과 CMS 설정이 일치한 후에 실행해야 하며, 그 전에 하면 곧 변경할 값을 캐시할 뿐입니다.

cv flush
# then Administer > System Settings > Cleanup Caches and Update Paths

3단계: CiviCRM이 생성하는 주소를 확인하세요

첫 페이지에 도달하는 것만으로는 거의 아무것도 증명하지 못합니다. CiviCRM은 CMS 안에서 실행되며, 중요한 페이지는 로그인 리디렉션, 관리 메뉴, 확장 리소스, 업로드된 파일 링크, 통합이 등록하는 모든 외부 콜백처럼 자체 URL을 만드는 페이지입니다.

대시보드를 불러오고 연락처 레코드를 열어 절대 링크가 있는지 페이지 소스를 확인합니다. 한 클라이언트 그룹만 도달할 수 있는 호스트 이름을 가리킨다면 페이지가 렌더링되었더라도 기본 URL은 여전히 잘못되었습니다. 올바른 이름이지만 잘못된 스킴을 가리킨다면 프록시 구성을 고쳐야 합니다.

주소를 정말 바꿔야 한다면 DNS 편집이 아니라 애플리케이션 마이그레이션으로 다루세요. 리소스 URL, 캐시, 게시된 링크, 이전 주소를 저장하는 모든 외부 통합을 검토한 뒤 한 번의 작업 창에서 함께 갱신해 아무도 반쯤 이전된 북마크를 들고 있지 않게 하세요.

요청 호스트 이름은 신뢰 결정이 아닙니다

요청 헤더에 특정 문자열이 있다고 해서 권한 있는 기본 URL을 선택해서는 안 됩니다. PHP는 서버 이름 값이 클라이언트가 제공한 호스트를 반영할 수 있는 Apache 구성을 문서화하며, 서버 주소 변수는 서버를 설명하는 것이지 방문자의 위치가 아닙니다. 둘 다 액세스 제어 메커니즘이 아니며, 그중 하나로 제어를 만드는 것이 사설 서비스가 잘못된 호스트에 잘못된 콘텐츠를 제공하게 되는 길입니다.

여러 호스트 이름이 정말 필요하다면 웹 서버, CMS, 애플리케이션 계층에 명시적 허용 목록을 구성하고 요청 호스트 이름이 승인된 항목 중에서만 선택하게 하세요. 임의의 입력이 절대 링크의 출처나 신뢰할 수 있는 리디렉션 대상이 되어서는 안 됩니다.

승인된 각 컨텍스트에서 로그인, 일반 내부 탐색, 하나의 리소스 요청이라는 같은 북마크로 마무리하세요. 페이지가 로드되었는지뿐 아니라 응답의 호스트 이름을 비교하세요. 이 세 요청 확인은 경로 문제와 아직 잘못된 주소를 생성하는 애플리케이션을 구분하며, 클라이언트 그룹당 약 일 분이 걸립니다.