Pi-hole กับ VPN บน Pi เครื่องเดียว: ระบบปฏิบัติการยังรองรับอยู่หรือไม่

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

สายรุ่นเป็นตัวกำหนดการรองรับ ไม่ใช่ชื่อตระกูล

ถามว่าโปรเจกต์ยังทดสอบกับรุ่นใด แล้วเขียนคำตอบเป็นสตริงเวอร์ชัน ไม่ใช่ Debian หน้า ข้อกำหนดเบื้องต้น ของ Pi-hole ระบุระบบปฏิบัติการที่รองรับกับสถาปัตยกรรม FTL ที่สร้างไว้ล่วงหน้าเป็นสองข้อกำหนดแยกกัน จำกัดการรองรับไว้ที่รุ่นที่ดิสทริบิวชันเองยังดูแล และเตือนว่ารุ่นย่อยหรือการกำหนดค่าที่ไม่ปกติอาจล้มเหลวได้แม้อยู่ในรายการที่รองรับ ถ้อยคำนี้สำคัญ: ตระกูลที่รองรับไม่ได้ครอบคลุมสมาชิกทุกตัว

อิมเมจเก่าที่ยังบูตบน Pi ของคุณไม่ใช่หลักฐานของการรองรับ บอร์ดยังดี ดัชนีแพ็กเกจล้าสมัย และความไม่เข้ากันจะปรากฏทีหลัง เมื่อตัวติดตั้งดึง dependency ที่รุ่นนั้นตอบสนองไม่ได้แล้ว

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

ทำให้เป้าหมายไบนารีตรงกับพื้นที่ผู้ใช้ที่คุณมี

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

uname -m
dpkg --print-architecture
grep -E '^(PRETTY_NAME|VERSION_ID)=' /etc/os-release
apt-cache policy pihole-ftl

ถ้าสองบรรทัดสถาปัตยกรรมไม่ตรงกัน คุณอยู่บนการตั้งค่าแบบผสม: ใช้ได้กับ Pi-hole เดี่ยว แต่เปราะเมื่อบริการที่สองต้องการไลบรารีเนทีฟ การแฟลชอิมเมจ 64 บิตที่สะอาดใหม่มักเร็วกว่าการสร้าง toolchain ที่ทำให้เกิดความไม่เข้ากันขึ้นใหม่

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

กล่องเดียว บริการสองอย่าง เจ้าของเครือข่ายหนึ่งราย

ตัดสินว่าใครเป็นเจ้าของการกำหนดแอดเดรส ตัวแก้ไขชื่อ และอุโมงค์ ก่อนแพ็กเกจแรกจะขึ้น เพราะไม่เช่นนั้นสองบริการจะอ้างหน้าที่เดียวกันและไม่มีใครชนะอย่างสะอาด ให้ Pi มีแอดเดรสคงที่ภายนอกพูล DHCP ที่เราเตอร์แจก และเก็บอุโมงค์ไว้บนซับเน็ตของมันเอง: 192.168.50.10 สำหรับ Pi และ 10.42.0.0/24 สำหรับอุโมงค์เป็นหนึ่งการแบ่งที่ใช้ได้ และตัวเลขเองเป็นเรื่องตามอำเภอใจตราบใดที่ไม่ชนกับสิ่งที่เราเตอร์ให้บริการอยู่แล้ว จากนั้นจดว่าองค์ประกอบใดตอบบนพอร์ต 53 ตัวใดแจก DHCP ถ้าคุณใช้ และตัวใดถือเส้นทางเริ่มต้นขณะอุโมงค์ขึ้น บนอิมเมจที่ไม่มีหน้าจอ งานสุดท้ายนั้นเป็นของ NetworkManager หรือ systemd-networkd และ การติดตั้งไคลเอนต์ผู้ให้บริการที่เขียนการกำหนดค่าตัวแก้ไขชื่อใหม่ด้วย คือทางที่ผู้คนจบลงด้วยอุโมงค์ที่ยังมีชีวิตและ DNS ที่ตายแล้ว

การแบ่งกล่องกันใช้ได้ การแบ่งบทบาทไม่ใช้ Pi-hole ต้องการเป็นผู้ฟังเดียวบนพอร์ต 53 และเดมอน VPN ต้องการดันการตั้งค่า DNS ของตัวเองไปยังไคลเอนต์ ดังนั้นเลือกว่าสองตัวนี้ไคลเอนต์ควรเชื่อใจตัวใด และกำหนดอีกตัวให้อยู่นอกทาง

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

ทำให้การอัปเกรดครั้งถัดไปเป็นส่วนหนึ่งของการเลือก

รุ่นที่คุณอัปเกรดไม่ได้คือเพดานการรองรับที่คุณยอมรับไปแล้ว ทดสอบกลไกการอัปเกรดบนการ์ดสำรองก่อนอุปกรณ์จะแบก DNS ของบ้านคุณ และอ่านว่าโปรเจกต์พูดอะไรเกี่ยวกับการข้ามสายรุ่น แทนที่จะถือว่าการอัปเกรดแพ็กเกจเพียงพอ

sudo apt update
apt-mark showhold
sudo apt full-upgrade
pihole -up

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

ก่อนกระโดด ส่งออกการกำหนดค่า Pi-hole สัญญาเช่าคงที่ และโปรไฟล์อุโมงค์ใด ๆ และยืนยันว่าคุณกู้คืนบนอิมเมจใหม่ได้ หลังกระโดด ทดสอบ DNS ปกติของไคลเอนต์ ทรัพยากรส่วนตัวหลังอุโมงค์ การเชื่อมต่อใหม่ และกฎส่งต่อใด ๆ บนเกตเวย์ กล่องที่บูตและตอบ ping แทบไม่ผ่านอะไรเลย

เมื่อไม่มีรุ่นเดียวที่เข้าทั้งสองบริการ

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

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

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