URL CiviCRM เดียวสำหรับผู้ใช้สำนักงานและ VPN: ขั้นตอนการตั้งค่า

แล็ปท็อปในสำนักงานควรเปิดบุ๊กมาร์ก CiviCRM เดียวกันที่โต๊ะทำงาน และอีกครั้งจากบ้านผ่าน VPN การออกแบบที่ทนต่อการใช้งานจริงคือที่อยู่มาตรฐานหนึ่งรายการ สมมติว่า https://crm.example.org/, พร้อมเส้นทางเครือข่ายที่ได้รับอนุมัติจากแต่ละตำแหน่ง และใบรับรองที่ใช้ได้กับชื่อนั้น VPN เปลี่ยนวิธีที่ไคลเอนต์ระยะไกลเข้าถึงเซิร์ฟเวอร์ มันไม่ควรเปลี่ยนตัวตนของแอปพลิเคชันเลย เพราะในขณะที่มันทำเช่นนั้น ทุกลิงก์ที่สร้าง การเปลี่ยนเส้นทาง และ callback ของการผสานรวมจะกลายเป็นปัญหาที่สองที่ต้องแก้

เลือก URL ก่อนเลือกเส้นทาง

เขียนที่อยู่ที่ต้องการก่อน รวมถึงองค์ประกอบเส้นทางใด ๆ ที่ CMS ต้องใช้ และถือเป็นจุดคงที่ ทุกสิ่งอื่นในคู่มือนี้เป็นรายละเอียดการนำไปใช้ที่เปลี่ยนได้โดยไม่ต้องแตะต้องมัน: คำตอบ DNS ที่แต่ละกลุ่มได้รับ กฎไฟร์วอลล์ที่อนุญาตให้ listener และ ว่าทราฟฟิกมาทางอุโมงค์หรือพอร์ตสวิตช์ภายใน.

บันทึกค่าสี่ค่าพร้อมกันในแผนการเข้าถึง เพราะมันทำงานได้เฉพาะเป็นชุดเท่านั้น URL มาตรฐาน คำตอบที่แต่ละกลุ่มไคลเอนต์ควรได้รับสำหรับชื่อนั้น เส้นทางและกฎการเข้าถึงสำหรับคำตอบนั้น ชื่อโฮสต์ที่เว็บเซิร์ฟเวอร์และใบรับรองได้รับการกำหนดค่าให้ให้บริการ เมื่อมีสิ่งใดเสียหายในภายหลัง องค์ประกอบที่เสียคือหนึ่งในสี่นั้น และคุณจะรู้ว่าคุณเปลี่ยนสิ่งใด

ขั้นตอนที่ 1: ทำให้ชื่อ resolve ได้อย่างถูกต้องสำหรับทั้งสองกลุ่ม

ทั้งสองกลุ่มควรได้รับคำตอบแบบส่วนตัวที่พวกเขาเข้าถึงได้จริง และเป็นเรื่องชอบด้วยเหตุผลที่คำตอบจะต่างกันตราบใดที่ชื่อไม่ต่างกัน ไคลเอนต์ LAN resolve ผ่านตัวแก้ไขภายใน ส่วนไคลเอนต์ VPN ต้องการนโยบายตัวแก้ไขที่ให้โซนเดียวกันแทนที่จะรั่วคำถามไปยังตัวแก้ไขสาธารณะและได้คำตอบสาธารณะที่ใช้ไม่ได้

ทดสอบชื่อจากแต่ละบริบทแทนการสันนิษฐาน และทดสอบเส้นทางโดยไม่ขึ้นกับ DNS ด้วยตัวเลือก resolve ของ curl ซึ่งตรึงที่อยู่ไว้สำหรับคำขอเดียว:

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

หากการทดสอบครั้งแรกคืนที่อยู่ที่ไคลเอนต์เข้าถึงไม่ได้ แสดงว่าเส้นทางอุโมงค์หรือรายการ split-tunnel คือปัญหา หากการทดสอบครั้งที่สองคืนการเปลี่ยนเส้นทางไปยังชื่อโฮสต์ที่คุณไม่ได้คาดไว้ ให้หยุดและอ่านส่วนหัว Location เพราะนั่นเป็นปัญหาแอปพลิเคชันและการเปลี่ยนเส้นทางไม่สามารถแก้ได้

ขั้นตอนที่ 2: จัดแนวเว็บเซิร์ฟเวอร์ ใบรับรอง และ URL ฐานของ CMS

listener ต้องได้รับการกำหนดค่าให้ให้บริการชื่อมาตรฐาน และใบรับรองต้องครอบคลุมชื่อนั้น การเรียกดูด้วยที่อยู่ดิบไม่ใช่วิธีเลี่ยง: มันทำให้เกิดชื่อไม่ตรงกัน อาจทำให้ขอบเขตคุกกี้เสียหาย และสอนผู้ใช้ให้คลิกผ่านคำเตือนที่คุณจะต้องอธิบายให้ผู้ตรวจสอบฟังในภายหลัง

หลังพร็อกซีย้อนกลับ ตรวจสอบว่าแอปพลิเคชันรู้ว่าคำขอมาทาง HTTPS แพลตฟอร์ม CMS ส่วนใหญ่สร้างลิงก์แบบสัมบูรณ์จากสคีมาที่ตรวจพบ และพร็อกซีที่สิ้นสุด TLS โดยไม่ส่งต่อสคีมาเดิมจะสร้างหน้าที่เต็มไปด้วย http:// ทรัพยากรที่เบราว์เซอร์อาจบล็อก กำหนดค่าพร็อกซีที่เชื่อถือได้และส่วนหัวที่ส่งต่ออย่างชัดเจนแทนที่จะปล่อยให้แอปพลิเคชันเดา

จากนั้นจัดแนว URL ฐานของ CMS และ CiviCRM CiviCRM เก็บ URL ฐานที่กำหนดไว้และมีวิธีที่รองรับในการคำนวณใหม่: การดำเนินการผู้ดูแลระบบ Cleanup Caches and Update Paths ซึ่งมีเอกสารอยู่ใน คู่มือการแก้ไขปัญหาการติดตั้ง CiviCRM เรียกใช้หลังจากชื่อมาตรฐานและการตั้งค่า CMS ตรงกัน ไม่ใช่ก่อนหน้านั้น ไม่เช่นนั้นคุณจะแคชค่าที่คุณกำลังจะเปลี่ยน

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

ขั้นตอนที่ 3: ตรวจสอบที่อยู่ที่ CiviCRM สร้างขึ้น

การเข้าถึงหน้าแรกพิสูจน์ได้น้อยมาก CiviCRM ทำงานภายใน CMS และหน้าที่สำคัญคือหน้าที่สร้าง URL ของตัวเอง: การเปลี่ยนเส้นทางเข้าสู่ระบบ เมนูผู้ดูแล ทรัพยากรส่วนขยาย ลิงก์ไฟล์ที่อัปโหลด และ callback ภายนอกใด ๆ ที่การผสานรวมลงทะเบียน

โหลดแดชบอร์ด เปิดบันทึกผู้ติดต่อ และดูซอร์สโค้ดของหน้าเพื่อหาลิงก์แบบสัมบูรณ์ หากลิงก์ชี้ไปยังชื่อโฮสต์ที่กลุ่มไคลเอนต์เดียวเท่านั้นเข้าถึงได้ URL ฐานยังคงผิดแม้หน้าเว็บจะแสดงผลแล้ว หากชี้ไปยังชื่อที่ถูกต้องแต่สคีมาผิด การกำหนดค่าพร็อกซีคือสิ่งที่ต้องแก้ไข

เมื่อที่อยู่ต้องเปลี่ยนจริง ๆ ให้ถือเป็นการย้ายแอปพลิเคชันไม่ใช่การแก้ไข DNS ตรวจสอบ URL ทรัพยากร แคช ลิงก์ที่เผยแพร่ และการผสานรวมภายนอกทุกรายการที่เก็บที่อยู่เดิม จากนั้นอัปเดตทั้งหมดในหน้าต่างเดียวเพื่อไม่ให้ใครถือบุ๊กมาร์กที่ย้ายไปเพียงครึ่งเดียว

ชื่อโฮสต์ในคำขอไม่ใช่การตัดสินใจเรื่องความไว้วางใจ

อย่าเลือก URL ฐานที่มีสิทธิพิเศษเพียงเพราะส่วนหัวของคำขอมีสตริงหนึ่ง PHP มีเอกสารเกี่ยวกับการกำหนดค่า Apache ซึ่งค่าชื่อเซิร์ฟเวอร์อาจสะท้อนโฮสต์ที่ไคลเอนต์ให้มา และตัวแปรที่อยู่เซิร์ฟเวอร์อธิบายเซิร์ฟเวอร์ ไม่ใช่ตำแหน่งของผู้เยี่ยมชม ทั้งสองอย่างไม่ใช่กลไกควบคุมการเข้าถึง และการสร้างกลไกจากสิ่งเหล่านั้นคือวิธีที่บริการส่วนตัวลงเอยด้วยการให้เนื้อหาผิดกับโฮสต์ผิด

หากจำเป็นต้องมีชื่อโฮสต์หลายชื่อจริง ๆ ให้กำหนดรายการที่อนุญาตอย่างชัดเจนที่เว็บเซิร์ฟเวอร์ CMS และชั้นแอปพลิเคชัน และให้ชื่อโฮสต์ของคำขอเลือกได้เฉพาะในรายการที่อนุมัติเท่านั้น อินพุตตามอำเภอใจไม่ควรกลายเป็นแหล่งของลิงก์แบบสัมบูรณ์หรือปลายทางการเปลี่ยนเส้นทางที่เชื่อถือได้

จบด้วยบุ๊กมาร์กเดียวกันในแต่ละบริบทที่อนุมัติ: การเข้าสู่ระบบ การนำทางภายในปกติ และคำขอทรัพยากรหนึ่งครั้ง เปรียบเทียบชื่อโฮสต์ในคำตอบ ไม่ใช่แค่ว่าหน้าโหลดหรือไม่ การตรวจสอบสามคำขอนั้นแยกปัญหเส้นทางออกจากแอปพลิเคชันที่ยังสร้างที่อยู่ผิด และใช้เวลาประมาณหนึ่งนาทีต่อกลุ่มไคลเอนต์