Một URL CiviCRM cho người dùng văn phòng và VPN: các bước thiết lập

Một máy tính xách tay ở văn phòng phải mở cùng một dấu trang CiviCRM tại bàn làm việc và một lần nữa từ nhà qua VPN. Thiết kế đứng vững trước tiếp xúc với người dùng là một địa chỉ chuẩn tắc duy nhất, giả sử https://crm.example.org/, với một đường dẫn mạng được phê duyệt từ mỗi vị trí, và chứng chỉ hợp lệ cho tên đó. VPN thay đổi cách một máy khách từ xa tiếp cận máy chủ. Nó không bao giờ được thay đổi danh tính của ứng dụng, vì ngay khi làm vậy, mọi liên kết được tạo, chuyển hướng và lệnh gọi lại tích hợp trở thành vấn đề thứ hai cần giải quyết.

Chọn URL trước khi chọn tuyến đường

Trước tiên hãy ghi lại địa chỉ dự định, bao gồm mọi thành phần đường dẫn mà CMS cần, và coi đó là điểm cố định. Mọi thứ khác trong hướng dẫn này là chi tiết triển khai có thể thay đổi mà không cần chạm vào nó: nhóm nào nhận câu trả lời DNS nào, quy tắc tường lửa nào cho phép trình lắng nghe và liệu lưu lượng đến qua đường hầm hay qua cổng chuyển mạch cục bộ.

Ghi bốn giá trị cùng nhau trong kế hoạch truy cập, vì chúng chỉ hoạt động như một bộ. URL chuẩn tắc. Câu trả lời mà mỗi nhóm máy khách nên nhận cho tên đó. Tuyến đường và quy tắc truy cập cho câu trả lời đó. Tên máy chủ mà máy chủ web và chứng chỉ được cấu hình để phục vụ. Khi có sự cố sau này, phần tử bị hỏng là một trong bốn thứ đó, và bạn sẽ biết mình đã thay đổi cái nào.

Bước 1: đảm bảo tên được phân giải chính xác cho cả hai nhóm

Cả hai nhóm nên nhận được một câu trả lời riêng tư mà họ thực sự có thể tiếp cận, và hợp lý khi các câu trả lời khác nhau miễn là tên không khác. Máy khách LAN phân giải qua trình phân giải nội bộ; máy khách VPN cần chính sách trình phân giải cung cấp cho họ cùng vùng thay vì rò rỉ truy vấn đến trình phân giải công cộng và nhận một câu trả lời công cộng mà họ không thể sử dụng.

Kiểm tra tên từ từng ngữ cảnh thay vì giả định, và kiểm tra đường dẫn độc lập với DNS bằng tùy chọn resolve của curl, vốn ghim địa chỉ cho một yêu cầu:

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

Nếu lần kiểm tra đầu tiên trả về một địa chỉ mà máy khách không thể tiếp cận, vấn đề là định tuyến đường hầm hoặc danh sách split-tunnel. Nếu lần kiểm tra thứ hai trả về chuyển hướng đến một tên máy chủ bạn không ngờ tới, hãy dừng lại và đọc tiêu đề Location, vì đó là vấn đề của ứng dụng và không thay đổi tuyến đường nào sửa được.

Bước 2: căn chỉnh máy chủ web, chứng chỉ và URL cơ sở của CMS

Trình lắng nghe phải được cấu hình để phục vụ tên chuẩn tắc, và chứng chỉ phải bao phủ nó. Duyệt bằng địa chỉ thô không phải là cách khắc phục: nó tạo ra sự không khớp tên, có thể phá vỡ phạm vi cookie, và dạy người dùng bấm qua các cảnh báo mà sau này bạn sẽ phải giải thích với kiểm toán viên.

Phía sau proxy ngược, hãy đảm bảo ứng dụng biết rằng yêu cầu đến qua HTTPS. Hầu hết các nền tảng CMS tạo liên kết tuyệt đối từ lược đồ được phát hiện, và một proxy kết thúc TLS mà không chuyển tiếp lược đồ gốc sẽ tạo ra một trang đầy http:// tài nguyên mà trình duyệt có thể chặn. Hãy cấu hình rõ ràng proxy tin cậy và các tiêu đề được chuyển tiếp thay vì để ứng dụng tự đoán.

Sau đó căn chỉnh URL cơ sở của CMS và CiviCRM. CiviCRM giữ URL cơ sở đã xác định của nó và cung cấp một cách được hỗ trợ để tính lại: hành động quản trị Dọn dẹp bộ nhớ đệm và cập nhật đường dẫn, được ghi lại trong hướng dẫn khắc phục sự cố cài đặt CiviCRM. Chạy nó sau khi tên chuẩn tắc và cài đặt CMS khớp nhau, không phải trước đó, nếu không bạn sẽ chỉ lưu vào bộ nhớ đệm một giá trị sắp thay đổi.

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

Bước 3: kiểm tra các địa chỉ mà CiviCRM tạo ra

Tiếp cận trang đầu chứng minh rất ít. CiviCRM chạy bên trong một CMS, và những trang quan trọng là những trang tự xây dựng URL của chúng: chuyển hướng đăng nhập, menu quản trị, tài nguyên tiện ích mở rộng, liên kết tệp đã tải lên và mọi lệnh gọi lại bên ngoài được một tích hợp đăng ký.

Tải bảng điều khiển, mở một bản ghi liên hệ và xem mã nguồn trang để tìm liên kết tuyệt đối. Nếu chúng trỏ đến một tên máy chủ mà chỉ một nhóm máy khách có thể tiếp cận, URL cơ sở vẫn sai dù trang đã hiển thị. Nếu chúng trỏ đến đúng tên nhưng sai lược đồ, cấu hình proxy là thứ cần sửa.

Ở nơi địa chỉ thực sự phải thay đổi, hãy coi đó là việc di chuyển ứng dụng chứ không phải chỉnh sửa DNS. Xem lại URL tài nguyên, bộ nhớ đệm, liên kết đã xuất bản và mọi tích hợp bên ngoài lưu địa chỉ cũ, sau đó cập nhật chúng trong một cửa sổ để không ai còn giữ một dấu trang đã di chuyển một nửa.

Tên máy chủ trong yêu cầu không phải là quyết định tin cậy

Đừng chọn một URL cơ sở đặc quyền chỉ vì một tiêu đề yêu cầu chứa một chuỗi cụ thể. PHP ghi lại các cấu hình Apache trong đó giá trị tên máy chủ có thể phản ánh một máy chủ do máy khách cung cấp, và biến địa chỉ máy chủ mô tả máy chủ, không phải vị trí của khách truy cập. Không điều nào trong số đó là cơ chế kiểm soát truy cập, và việc xây dựng một cơ chế từ chúng là cách một dịch vụ riêng tư cuối cùng phục vụ nội dung sai cho máy chủ sai.

Nếu thực sự cần nhiều tên máy chủ, hãy cấu hình danh sách cho phép rõ ràng trên máy chủ web, trong CMS và ở lớp ứng dụng, và để tên máy chủ của yêu cầu chỉ chọn trong số các mục đã được phê duyệt. Đầu vào tùy ý không bao giờ được trở thành nguồn của liên kết tuyệt đối hay đích chuyển hướng đáng tin cậy.

Kết thúc bằng cùng một dấu trang trong mỗi ngữ cảnh được phê duyệt: đăng nhập, điều hướng nội bộ thông thường và một yêu cầu tài nguyên. So sánh tên máy chủ trong các phản hồi, không chỉ việc trang có tải hay không. Kiểm tra ba yêu cầu đó tách một vấn đề đường dẫn khỏi một ứng dụng vẫn tạo ra địa chỉ sai, và mất khoảng một phút cho mỗi nhóm máy khách.