Nextcloud ผ่าน VPN เท่านั้น: ก่อนอื่นจดทะเบียนทุกทางเข้า

แผน Nextcloud ที่ใช้ VPN เท่านั้นล้มเหลวเมื่อปกป้องเบราว์เซอร์แต่ลืมไคลเอนต์ซิงค์ หน้าเว็บ เอนจินซิงค์บนเดสก์ท็อป การอัปโหลดจากมือถือ เครื่องมือ WebDAV และผู้รับลิงก์ที่แชร์ล้วนต้องการเส้นทางไปยังบริการเดียวกัน และแต่ละรายการก็อาจเปิดเผยทางเข้าที่ต่างกันได้ จดทะเบียนทั้งหมดก่อนปิดสิ่งใด ที่รายการนั้นคือขอบเขตจริง

ทำตามเช็กลิสต์ตามลำดับ ข้อแรกกำหนดว่าคำว่าส่วนตัวหมายถึงอะไรสำหรับการติดตั้งนี้ ข้อถัดไปทดสอบว่าการติดตั้งตรงกับนิยามนั้นจริงหรือไม่

กำหนดความหมายของส่วนตัวก่อนเปลี่ยนขอบเขต

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

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

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

จดทะเบียนทุกทางเข้าและทุกชื่อ

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

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

จากนั้นบล็อกทางเข้าที่คุณไม่ได้เลือก แบ็กเอนด์ส่วนตัวที่มีส่วนหน้าสาธารณะไม่ใช่ดีไซน์ VPN เท่านั้น และกฎไฟร์วอลล์ที่ครอบคลุมเพียง IPv4 จะทิ้งตัวรับฟัง IPv6 ไว้เปิด ปิดทั้งสองตระกูลและทั้งสองชื่อในการเปลี่ยนแปลงเดียวกัน

ให้ไคลเอนต์แต่ละรายมีชื่อบริการเดียว

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

ไคลเอนต์ที่เชื่อมต่อผ่านที่อยู่ IP ที่ไม่เกี่ยวข้องไม่ควรต้องปิดข้อผิดพลาดใบรับรองเพื่อให้ดีไซน์ทำงาน ชื่อที่มั่นคงยังป้องกันไม่ให้ไคลเอนต์ซิงค์สร้างรายการเซิร์ฟเวอร์ซ้ำเมื่อที่อยู่เปลี่ยน นั่นคือความต่างระหว่างบริการส่วนตัวกับ IP ส่วนตัว

เปิดการตรวจสอบใบรับรองไว้ เครือข่ายส่วนตัวลดการเปิดเผยแต่ไม่ได้ทำให้การเชื่อมต่อ TLS ที่ไม่ได้ตรวจสอบเป็นที่ยอมรับ และไคลเอนต์ที่เคยชินกับการเพิกเฉยคำเตือนจะเพิกเฉยต่อคำเตือนนั้นในเครือข่ายอื่นด้วย

จำกัดการเข้าถึงเครือข่าย ไม่ใช่ทั้ง LAN

อนุญาตให้ผู้ใช้ที่ลงทะเบียนเข้าถึงบริการ Nextcloud และสิ่งที่ต้องพึ่งพา และเก็บการดูแลเซิร์ฟเวอร์ไว้บนเส้นทางแยก VPN ที่ ปล่อยให้ไคลเอนต์เข้าไปในเครือข่ายบ้านหรือสำนักงานทั้งหมด ให้ไคลเอนต์นั้นมากกว่าที่แอปพลิเคชันต้องการมาก

การเข้าถึง VPN ไม่ได้แทนที่บัญชี สิทธิ์ หรือการยืนยันตัวตนเพิ่มเติมของ Nextcloud แอปพลิเคชันยังคงตัดสินว่าผู้ใช้คนใดอ่านไฟล์ใดได้ และชั้นเครือข่ายไม่ควรเป็นเพียงการควบคุมเดียว

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

ทบทวนทุกขั้นตอนการทำงานนอกเบราว์เซอร์

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

เครื่องมือ WebDAV และไคลเอนต์ปฏิทินหรือรายชื่อเป็นการผสานรวมแยกที่มีการกำหนดค่าของตนเอง ไคลเอนต์ที่แคช URL สาธารณะจะยังคงลอง URL นั้นหลังการเปลี่ยนขอบเขต และความล้มเหลวดูเหมือนปัญหาแอปพลิเคชัน

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

สหพันธ์และการผสานรวมเซิร์ฟเวอร์ถึงเซิร์ฟเวอร์ต้องการการปฏิบัติเช่นเดียวกัน สิ่งเหล่านี้คือความสัมพันธ์ของการเข้าถึงระหว่างการติดตั้ง และการติดตั้งแบบส่วนตัวเท่านั้นต้องบอกว่าได้รับการสนับสนุนหรือไม่

ยอมรับทั้งกรณีที่อนุญาตและกรณีที่ปฏิเสธ

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

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

สุดท้าย ทบทวนการตั้งค่าแอปพลิเคชันที่สับสนกับนโยบายเครือข่ายได้ง่าย trusted_domains แสดงรายชื่อที่อินสแตนซ์ยอมรับ ไม่ใช่รายการอนุญาต IP ของไคลเอนต์ หากพร็อกซี่ย้อนกลับให้ข้อมูลที่อยู่ trusted_proxies ต้องระบุพร็อกซี่จริง และเฮดเดอร์ที่ส่งต่อควรยอมรับจากพร็อกซี่นั้นเท่านั้น

ทำงานเสริมความแข็งแกร่งตามปกติไปพร้อมกับการเปลี่ยนเครือข่าย: เก็บข้อมูลและข้อมูลสำรองออกจากเส้นทางเว็บที่ไม่ตั้งใจ แพตช์แอปพลิเคชัน ปกป้องการเข้าถึงของผู้ดูแลระบบ และรักษาการกู้คืนให้ใช้งานได้ VPN กำจัดพื้นผิวทางเข้าหนึ่งอย่าง แต่ไม่ได้ทำให้ไคลเอนต์ที่ลงทะเบียนน่าไว้วางใจ